In this instance, it would have been nice, assuming one wanted a perfect system, if RSCS had received a SHUTDOWN signal and had stopped gracefully. However, the fact that it is normal behavior under the circumstances, as explained by Les, is satisfactory.
What is it with Keepalive (TCPIP) vs. KEEPALIV (RSCS), anyway? IIRC, you and others have said that Keepalive causes packets to be sent while KEEPALIV does not. In this case the values on the side where the RSCS connection appeared to stay up were, Keepalive options: interval=20, sendgarbage true; RSCS parm: KEEPALIV=NO. That said, it did not seem to matter what the RSCS parm was. The same behavior was exhibited when KEEPALIV=YES was used. In other words, KEEPALIV appeared to be a unary switch :-) Regards, Richard Schuh -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, April 23, 2007 4:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCPNJE On Monday, 04/23/2007 at 10:11 MST, "Schuh, Richard" <[EMAIL PROTECTED]> wrote: > The situation: > > 1. 2 VM systems, 1 first level and the other as a guest, connected via > TCPNJE. KEEPALIV=NO specified in the PARM of each. > > 2. The guest shuts down and logs off without draining the link. > > 3. The first level system shows the link as connected long (sometimes > days) after the second level system logs off. > > Is this normal or do I need to open a problem? That is exactly why keepalive packets were invented. If you want to know that a TCP connection is no longer "viable" you have send keepalives. Have cake. Eat cake. Pick one. :-) It comes with a downside in that the link will also drop if there is a loss of connectivity (a routing failure) for the keepalive packet, even if you aren't actively trying to send a file at that moment. Alan Altmark z/VM Development IBM Endicott
