On Sep 7, 2005, at 3:28 AM, Large, M (Matthew) wrote:
Hi SMers, I picked up this message last night after a scheduled event failed, but I was not expecting to read what I read: 06-09-2005 17:43:33 ANR1639I Attributes changed for node CHEETAH: TCP Address from 172.17.40.228 to 172.17.44.56. (SESSION: 3310) 06-09-2005 17:43:42 ANR0403I Session 3310 ended for node CHEETAH (AIX). (SESSION: 3310) 07-09-2005 01:01:12 ANR2716E Schedule prompter was not able to contact client CHEETAH using type 1 (172.17.40.228 1501). (SESSION: 623) It would make sense if TSM had attempted to contact the client with the new TCP address, but it tried on the old TCP address. My question is, why?
More inspection of your configuration may reveal the answer. Perform a detailed Query Node on that client, and see if the High-level Address has a hard-coded network address in it. You suggest that your scheduled backups are overnight. In that case, the 17:43 contact would seem to have been manually invoked. That would have set the node's TCP/IP Address value to the session origination address, but would not change the node's High-level Address. There is much we don't know about intervening events. You may want to perform Activity Log research. Also review the client's options file for its settings. We also don't know from your posting whether these IPaddresses both reflect the same physical client, which may have multiple NICs, participating in two (private, non-routed) subnets. If this is the same client, then the larger issue is why the server prompted schedule could not contact a scheduler process within the client: maybe firewall issues, maybe no process running, or no CAD. On the other hand, these may be two different computers, both posing as CHEETAH, which is not good. Richard Sims http://people.bu.edu/rbs
