Thanks for all the thoughts!

>The 'register node' and 'update node' commands have a
>'sessioninitiation' parameter. The default value, 'clientorserver',
>would be needed for the backup arrangement you describe for clients
>outside the firewall. The other possible value, 'serveronly', would
>cause these backups to fail, possibly with the symptoms you describe.

Will check it out.


>We have a firewall rule that allows all of the DMZ servers
>to contact the TSM servers and the TSM servers are
>allowed in on specific ports.
>In the opt files we have these lines:
>httpport yyyy
>webports xxxx zzzz

I'm not a firewall person - but the rules we have for the other five tsm
servers all work just fine.
It's just this one grrrrrr tsm server.  THey've checked and checked.


>compare the "q opt" output from an instance that works with the instance
>that doesn't.  There might be a conservative timeout setting.

Yes.  We've done that many times.  That's what makes this such
an frustrating problem.  it looks the same as the other servers.
So does the AIX setup, so does the fw rules (from what the fw folks
say - except for a diff ip addr).


>Other long-shot things to compare are "q node (NODENAME) f=d" for the
>specific nodes that are having trouble and "q stat"

Will do.

>I've had to use schedmode polling to get some firewall backups to run.

Yes, we've had to do this also for some nodes to get them to work.
Some nodes just won't work unless we change to polling.  The nodes
behind firewalls just don't work with this one tsm instance, but if we
move
the node to one of the other instances - poof (technical term) - it works.


>You doubtless checked the DNSLOOKUP option, and set it the
>same way on all your servers.
>Is it possible that the DNS for the problem client is also
>the only DNS that is also behind the firewall?   - Margaret

Actually, no . . .not familiar with that options.  WIll have to
read up on it.


Now . . .maybe I brought up this problem too quickly.  It turns out
the firewall folks missed some firewalls, so rules were not made
on some.  The tsm6 instance (where fw backups work) is having failed
backups because of this.  It could be that our testing last friday
evening was with a firewall'ed nodes for which there weren't
any rules!!

Nothing is simple . . . .

Thanks

Rick




-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.