Les, Our posts crossed on the net. I've already updated the PMR, included your reply (idle curiosity: I wonder how long it would have taken level 2 to find this result?), and asked how best to appeal the current JES2 solution.
Thanks again for your quick response! Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Les Geer (607-429-3580)" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 01/15/2007 01:26 PM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Can RSCS start a TCPNJE link and keep listening for the remote side to start? See the append I just posted, I don't think RSCS maintenance will provide any change in this behavior. I recommend opening a PMR to JES support and complain about this behavior. If the JES side is started, the link will connect correct? They need to provide another approach to slow RSCS connect requests down or cause RSCS to just wait rather than this approach. Best Regards, Les Geer IBM z/VM and Linux Development >Thanks, Colleen. I had already opened the "ASK" PMR before seeing your >post. >The PMR includes the LINKDEF, and PARM, as shown below: > >LINKDEF UTR TYPE TCPNJE ASTART CL * NODE UTR QUEUE PRI FORM * >PARM UTR JOBNAME=USERID HOSTNAME=LINMPUTR1 LCLPORT=175 RMTPORT=175 > >The LINK name, NODE name, and PARM name are all the same: UTR >We can pursue this in the PMR if you like, and report back here in case >someone else experiences the same situation. > >Again, this *could* be related to our ancient RSCS maintenance level of >9902, but I did not see any apparently-related fixes. > >Mike Walter >Hewitt Associates >Any opinions expressed herein are mine alone and do not necessarily >represent the opinions or policies of Hewitt Associates. > > > > >"Colleen Brown" <[EMAIL PROTECTED]> > >Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> >01/15/2007 01:10 PM >Please respond to >"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> > > > >To >IBMVM@LISTSERV.UARK.EDU >cc > >Subject >Re: Can RSCS start a TCPNJE link and keep listening for the remote side to >start? > > > > > > > >Remember that the LINKDEFINE for RSCS contains both a Link Name and a Node >Name. Could it be a mismatch with one of these? According to the RSCS >code we have received a reason code of 1 in the CRR control record. This >indicates a node mismatch. If reviewing your configuration doesn't find >the problem, I would suggest an RSCS Link trace when you are starting the >link. > >Colleen M Brown >IBM z/VM and Related Products Development and Service > > >Kris Buelens <[EMAIL PROTECTED]> >Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> >01/15/2007 01:42 PM > >Please respond to >The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> > > >To >IBMVM@LISTSERV.UARK.EDU >cc > >Subject >Re: Can RSCS start a TCPNJE link and keep listening for the remote side to >start? > > > > > > > > >Note too that when a TCPNJE links breaks, RSCS will not attempt to >restart, unless... >your create a "LinkName GCS" Rexx exec and place an > Address RSCS 'START linkname' >inside it. Still not 100% perfect I learned, but it helps. Yes, SNA links >has fewer start problems. > >2007/1/15, Mike Walter <[EMAIL PROTECTED]>: > >Thanks, Dave - but your being able to do it does not explain why we get >the error msgs when attempting to start the TCPNJE link (not SNANJE) and >let it wait for the JES2 side to start. Perhaps it is old maintenance? >But an IBMLink "SIS" search did not turn up anything. > >Mike Walter >Hewitt Associates >Any opinions expressed herein are mine alone and do not necessarily >represent the opinions or policies of Hewitt Associates. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
