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
