We are seeing strange behavior with one of our client systems since it
was moved behind a firewall. The client is a Windows XP system with TSM
6.2.2.0 client code. It sends backups to a TSM 6.2.2.0 server running 
under zSeries Linux. Before the firewall was introduced, the client was
able to run backups with prompted mode scheduling. When the firewall was
introduced, the client was given a new IP address and the old address was
transferred to the firewall. The backups stopped running when the firewall
was introduced. The messages reporting failed attempts to contact the
client system indicated that the TSM server was trying to contact the client
using the old IP address. Backups started running again after the client
system administrator added a 'tcpclientaddress' option specifying the new
IP address to dsm.opt.

According to the firewall administrator, the only traffic the firewall is
currently blocking is for automatic distribution of software patches (the
system is subject to regulatory requirements for explicit control of
configuration changes).

The 'TCP/IP Address' line in the output from 'query node' with 'f=d' shows
the new address, and did so before the introduction of the 'tcpclientaddress'
option. All ANR0406I session start messages for the client show the old
address (now the firewall address), and did so before the introduction of
the 'tcpclientaddress' option. According to the firewall administrator,
the firewall is not configured for NAT (Network Address Translation).

I suspect that the address in an ANR0406I message is the source address of
one of the packets involved in the TCP session initiation process, but I
cannot find any documentation that says this explicitly. Does anyone know
of an authoritative statement on this point? Does anyone have a theory that
would account for the combination of behaviors described above?

Thomas Denier
Thomas Jefferson University Hospital