If I set ITO to 0, the link is dropped immediately upon being started. If I set it to 99, I get the same 22.5 minute timeout that I got when I let ITO default to 100.
The MVS folks say that their TCPNJE link between 2 MVS systems has no problem and that they let the ITO default of 100 stand. Aarrggghhhh! I may have to dig into z/OS JES documentation to determine what should be specified where. The MVS folks here may not be willing to share their JES definitions. They sometimes are very defensive. >From your description, it appears likely that TCPIP's Keepalive packet is what is discovering that the MVS side has gone away and then TCP/IP interrupts RSCS with the bad news. Regards, Richard Schuh -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, March 15, 2007 10:33 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCPNJE On Thursday, 03/15/2007 at 09:35 MST, "Schuh, Richard" <[EMAIL PROTECTED]> wrote: > Les, > > We have a Keepalive interval of 20 with sendgarbage true in our TCP/IP > definitions and have let the Inactivity Time Out Parm for the TCPNJE > link default to 100, which means there will be no inactivity time out > from our side. These parameters work nicely when used on VM-VM links. > > The timing makes it appear as though the connection is being broken > from the z/OS side some time before the Keepalive interval expires. > When it does expire, the Garbage packet is transmitted. There is a > time out on the garbage packet, which triggers the connection time out > messages and action. > > Does this seem a plausible scenario? What does the JES definition look like? Maybe its ITO is less than 20 minutes? BTW, keepalives are transparent to the applications (RSCS & JES) - they don't see any traffic, even with "sendgarbage true". The purpose of the keepalive is so that you can find out sooner if the remote host has died unexpected or if your communications path was lost. This is different from, say, telnet support for TimerMarks which is an app-to-app heartbeat. This means that a keepalive packet sent from VM will not prevent the partner's inactivity timer from popping. If you don't want the links to go down, both sides must have ITO=0 (or the moral equivalent). Alan Altmark z/VM Development IBM Endicott
