What I think is happening here, since it was mentioned that the problem only occurs when the JES link has not been started is, JES decided to make an implementation change to stop RSCS from retrying connect attempts until the JES link had started. What they decided to do was to reject the RSCS connect request with the node mismatch error to cause the RSCS link to drain. I don't believe the RESTART exec will be called in this case as it is viewed as an error requiring operator intervention. One customer had complained RSCS is repeatedly trying to restart the link and this was their solution.
Best Regards, Les Geer IBM z/VM and Linux Development >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. > > > >>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. >> >> >>>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. >>>
