I fight firewall issues with a couple of tests.
From the TSM server: PING <IPofNode> TELNET <IPofNode> <ListeningPort> Typically, the node is listening on 1501 I believe. It should be specified in the node dsm.opt file. Try stopping/starting the nodes TSM Scheduler service, then try the TELNET again. If PING works, but the TELNET doesn't, you've likely got a firewall block. ------------------------------------------------ Harold Vandeventer Systems Programmer State of KansasĀ - Department of Administration - Office of Information Technology Services harold.vandeven...@ks.gov (785) 296-0631 -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Thomas Denier Sent: Friday, June 01, 2012 1:54 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Address in ANR0406I message 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 [Confidentiality notice:] *********************************************************************** This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. ***********************************************************************