Richard
        Thanks for your post.  It seems odd to me too that it doesn't
spell out the IP address when it tries to connect, but when you issue a
'q node stlo-mpvadm f=d'  the TSM scheduler clearly has the correct
address cached for it:
...
                   TCP/IP Name: STLO-MPVADM
                TCP/IP Address: 10.52.27.204 
... 

However, it may attempt to do a DNS resolve anyway, or a reverse resolve
on the IP address, and that is when it gets into trouble.

The DNS inconsistency only exists for this one client, and because of
how Active Directory works, I will have to reboot the client to fix it,
which will take a few days to plow through the bureaucracy.

Best Regards,

John D. Schneider 
Phone: 314-364-3150 
Cell: 314-750-8721
Email:  John.Schneider AT Mercy DOT net 


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: Thursday, September 18, 2008 11:15 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM scheduler can't reach TSM client even though
it seems to know it's IP address.

John -

The ANR8213W message is conspicuously deficient in not parenthetically
including the IP address along with the network name that it's
reporting, such that you don't know for certain what address the TSM
server is using in making the connection attempt.  With DNS awry at
your location, it may be that in the last client-server interaction
that an address was obtained for the next interaction, where that
address is no longer valid.  IBM Technote 1296826 goes into other
aspects of this situation.

I would not fault TSM in the missed schedule: I would not want my
server to be interacting with dubious network addresses where
supposedly secured host data is involved.

Flakey DNS is a very bad situation, and needs to get permanently fixed
there.  If you have good Security people there, they should be railing
on people about the ramifications of erroneous network addresses being
given out by your DNS servers.  You can look into the DNSLOOKUP option
for your TSM server, but there remains the larger issue of bad
addresses being given out in the environment in general.

    Richard Sims
This e-mail contains information which (a) may be PROPRIETARY IN NATURE OR
OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only for the
use of the addressee(s) named above. If you are not the addressee, or the
person responsible for delivering this to the addressee(s), you are notified
that reading, copying or distributing this e-mail is prohibited. If you have
received this e-mail in error, please contact the sender immediately.