Session rejected: TCP/IP connection failure [Same as ANS1017E]
This is what the client sees and reports, but has no idea why.
The cause is best sought in the ADSM server Activity Log for that time.
Could be a real datacomm problem; or...
Grossest problem: the TSM server is down.
If you get this condition after supposedly changing the client and server to use a different port number (e.g., 1502), and the Activity Log has no significant information about the attempted session, use 'netstat' or 'lsof' or similar utility in the server operating system to
verify that the *SM server is actually serving the port number that you believe it should be. (You *did* code the port numbers into both the client and server options files, right?)
An administrator may have done a 'CANcel SEssion'.
If during a Backup, likely the server cancelling it due to higher priority task like DB Backup starting and needing a tape drive...particularly when there is a drive shortage. Look in the server Activity Log around that time and you will likely see "ANR0492I All drives in use. Session 22668 for node ________ (AIX) being preempted by higher priority operation.".
Or look in the Activity Log for a "ANR0481W Session NNN for node () terminated - client did not respond within NN seconds." message, which reflects a server COMMTimeout value that is too low.
Message "ANR0482W Session for name () terminated - idle for more than N minutes." is telling you that the sever IDLETimeout value is too low. Remember that longstanding clients may take considerable time to rummage around in their file systems looking for new files to back up.
Another problem is in starting your client scheduler process from
/etc/inittab, but failing to specify redirection - you need:
dsmc::once:/usr/bin/dsmc sched > /dev/null 2>&1 # TSM scheduler
An unusual cause is in having the client and server defined to use the same port number!
Might also be a firewall rejecting the TSM client as it tries to reach the server through that firewall.
|
No comments:
Post a Comment