Hi Wanda, Good suggestion re: firewalls :-)
About the use of FTP: while a failure in FTP would lend support to the suggestion that this is a network problem, it is a *very* common mistake to assume that a successful test with FTP exonerates the network. I have worked on many dozens of these kinds of problems, and it is my experience that in almost every instance, FTP works just fine; yet ultimately the problem *is* somewhere in the network. This doesn't mean that the problem *can't* lie in TSM; but statistically speaking, the odds are very much against it. This is why I usually recommend using a sniffer and other network diagnostic tools to see what is happening at the network layer (especially since the connection is being broken by the network). One other thing that is sometimes worth trying, especially if the dsm.opt and dsm.sys files are heavily customized, is to use a very stripped down options file. Just use the minimal items necessary to establish a connection with the server: COMMMETHOD, TCPSERVERADDRESS, TCPPORT, NODENAME, and PASSWORDACCESS GENERATE (if GENERATE is used, which is usually the case). Don't specify *any* tuning parameters. Then see if the problem still occurs. Regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS Internet e-mail: [EMAIL PROTECTED] (change eye to i to reply) The only dumb question is the one that goes unasked. The command line is your friend. "Good enough" is the enemy of excellence. "Prather, Wanda" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 01/17/2003 09:37 Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject: Re: tcp layer problem If by chance this client is backing up through a firewall, check the timeout parms on the firewall. TSM client tends to send data in spurts, because a lot of time is spent noodling around in directories looking for things to back up. Many times we have seen a firewall causing this behavior where it closes the session, then the client restarts the session, firewall closes the session , cleint restarts the session, etc. Will eventually finish, slowly. You have to increase the timeout values on the firewall so it will allow the session to idle for for a while without closing it. If that's not it, my best tool for diagnosing network errors is a plain FTP. Take a sizeable file and FTP it to the TSM server several times. If that also has problems, it should convince your network people that the problem is somewhere in your network... -----Original Message----- From: Conko, Steven [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: tcp layer problem ive been going round and round with tsm support on this issue... we have an AIX 4.3.3 client that has been upgraded several times all the way to 5.1.5 client version without success backing up to an AIX 4.3.3 tsm 4.2.2 server over a 10/100 ethernet network (100 Full Duplex, no autonegotiate.) there arent any network errors and the switches are all configured correctly, and the tsm server is fine. they are beginning to insist our problem is system/network level... error: ANS1809W Session is lost; initializing session reopen procedure. appears almost constantly during backups. usually it will EVENTUALLY finish with a few errors but take forever to run. all our parameters appear to be okay by tsm support standards. with the combonation of the server message saying session was terminated they say the client is severing the connection... that tsm is getting the message from a lower layer. we dont have any network errors appearing anywhere else on the system for any other applications, there are no errors in errpt or /var/adm/messages and diags come back fine. what else can i do to diagnose this problem?