Well THANK YOU, Les!
How courteous of JES2. Can we make a similar change to RSCS to bollix up
JES2 when it keeps asking about something? ;-)
Nice error indication they picked, eh?
This does sound like it could be the problem. The link was defined
dynamically to JES2 to allow us to test the connection, but the dynamic
definition was removed and will stay undefined for a little longer.
Do you suppose that (knowing how helpful the VM side of the company is)
the msg "DMTTNE185E Link name mismatch -- link UTR deactivated" could be
updated to include the JES2 over-reaction as problem cause? Sure would
have saved me a lot of time looking for an error on the VM side, an error
that
did not exist!
I'll consider appealing the JES2 response. I can't imagine that RSCS was
causing a performance issue by trying to restart too frequently. On the
other hand, failing to let RSCS keep retrying can cause an extended
connection outage ("denial of service") when JES2 finally does start its
side and restarting the RSCS side require manual intervention.
Thanks for the description. I doubt that would have turned up in any doc
to which customers have access!
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:19 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?
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.
>>>
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.
