ADSM-L

Re: TCP/IP NAME TCP/IP ADDRESS

2003-09-21 22:07:32
Subject: Re: TCP/IP NAME TCP/IP ADDRESS
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Sun, 21 Sep 2003 06:49:59 -0400
>Need a little assistance on this.
>I issue "q node f=d" from the server side for a NODE_A, I get a TCP/IP NAME and
>TCP/IP ADDRESS that are incorrect (say NODE_B). At some point I may have
>connected virtually w/ the TCP/IP NAME (NODE_B) that I'm seeing, but even after
>I connect from the local host, NODE_A, the TCP/IP NAME and TCP/IP ADDRESS still
>reflect NODE_B's information.
>I've seen this on a few instances.  What drew this to my attention is the fact
>that I had 8 sessions started for one archive on NODE_A and no "resource"
>definition in the dsm.sys.  When I checked the dsm.sys on NODE_B, lo and 
>behold,
>resource utilization is set to 10.  What am I missing?
>
>Server Platform Z/os  running TSM Server v5,1,6.1
>NODE_A Client Platform Sun2.8 running BAclient TSMv4,2,2.1
>NODE_B Client Platform Sun2.8 running BAclient TSMv4,2,1.0
>
>Any help would be greatly appreciated.  thx.

Joseph - I would first check your client options files as Zlatko suggests.
         Do 'dsmc q opt', and check the modification datestamps on the files
to see if someone induced change (TCPCLIENTAddress, NODename, DEFAULTServer).
It would be unlikely, but check that no DSM_* environment variables are causing
use of unexpected options files.

I would also do 'netstat -i' and 'netstat -in' on those Solaris clients to
verify that what they think they are matches what you think they are...that
no "interesting" network configuration changes have transpired.

If these clients perform TSM actions at distinctly different times, examine
dsmaccnt.log for hostnames being what they should in there and, if not, look
back to see when it apparently changed, and pursue from there.

   Richard Sims, BU

<Prev in Thread] Current Thread [Next in Thread>