Do they have keepalives turned on? I do not know whether they do or not. Whenever I ask, I get an answer befitting a lawyer; something like, "I think we have allowed it to default and I think the default probably is to keep the link alive at all times." I have suggested that they look at their setup to verify it and all I get are mumbles.
Have cake. Eat cake. It's a choice. Make mine chocolate fudge cake with dark chocolate icing. Now they are trying to point to APAR VM61470. If I read things correctly, it (a) has not been closed and there is no PTF, and (b) probably is not relevant to the situation at hand (the systems get signed on and can send files back and forth so long as the link is not left idle). If that is the problem, can I get the PTF before it is created? Les Geer, You must be seeing this - I have just restarted the link specifying "parm host=10.205.32.89 keepaliv=yes ito=100" so we will see if that has any effect. If I were to bet on it, I would say that it will not fix the problem. "keepaliv" (no ending "e") appears to have been accepted. 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 2:37 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCPNJE On Thursday, 03/15/2007 at 12:24 MST, "Schuh, Richard" <[EMAIL PROTECTED]> wrote: > 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. Sorry. I meant ITO=100. (Never timeout.) > 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. Do they have keepalives turned on? > 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. Right. The jury is still out on the usefulness of keepalive packets, btw. IP was *designed* to tolerate path failures and to automatically route around them, not get all bent out of shape and start whining. It comes at the price of the application not discovering this until "too late". That is, until the app actually tries to use the path. "If only the network could have been repaired right *before* I needed it!" Personally, I'd specify KEEPALIV=NO. Have cake. Eat cake. It's a choice. Alan Altmark z/VM Development IBM Endicott
