ADSM-L

Re: [ADSM-L] Client connection makes TSM server neurotically talk to itself.

2007-09-14 08:38:59
Subject: Re: [ADSM-L] Client connection makes TSM server neurotically talk to itself.
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 14 Sep 2007 08:35:59 -0400
On Sep 13, 2007, at 8:04 PM, Steven Harris wrote:

Hi All
I've got some new windows nodes just defined  on two different AIX TSM
servers, and they are getting ANR8214E errors with the 127.0.0.1
address on
their overnight schedules. This is the same issue that Allen Rout
posted
about on July 31 (post included below).  Now the funny thing is
that I set
up a clientaction backup yesterday on these nodes, recycled the CAD
Service
and the clientaction backup ran with no problem, the client then
found its
next schedule and all appeared to be well, but then, last night more
ANR8214 errors.

Steve -

Some basic stuff to look at:  Is the service/process (still) running
on the client and looking healthy (not corrupted)?  Does lsof or
similar process inspection command show the dsmcad process with a TCP
port in Listen state?  Are there any errors reported in the client
dsmerror.log or dsmwebcl.log?  Are there any indications of system
problems in the Windows Event Log around the time the problem
started?  Do 'dsmc q opt' and assure that 127.0.0.1 is not
inadvertently defined in the client.

My suspicion is that the client somehow managed to believe that its
network address was the loopback 127.0.0.1 address (maybe due to a
NIC hiccup, momentarily leaving it with only the local loopback
address) and communicated that to the TSM server as its most recent
address to be used for the server to next prompt the client.  You
could check your Activity Log for all recent records of "127.0.0.1"
for some sense of what/when.  One measure you might try is to comment
out the TCPCLIENTAddress and TCPCLIENTPort lines in the client
options file: when the TSM server does not get these assigned values
from the client, it will go back to the last known ip and port
address listed in the TSM database.  If this persists and cause
cannot be determined, you may have to resort to coding the HLA and
LLA of the client in its Node definition.  There may be a Windows
defect causing this: assure those systems have recent service.

  what I can think of,  Richard Sims  at Boston University