Chris, I think I can help. I ran across a similar issue a while ago. CICS is configured to reestablish a connection when it "sees" a abnormally terminated session such as the user closing a TN3270 window. The behavior is governed by CICS settings. I used to work with a certain awesome CommServ/CICS guy that indicated that the trouble is most likely the CREATESESS(YES) on the TYPETERM definition. When the terminal is autoinstalled, CICS will issue a message indicating what TYPETERM was used. Check the MSGUSR message DFHZC6935I for the details. If the TYPETERM has CREATESESS(YES) specified, then CICS will attempt to reestablish the connection after the initial auto-install of the terminal has been done. Normally, CREATESESS(YES) is used for things like printers to allow CICS to initiate the session. Of course VTAM is just doing what is normal and trying to be helpful but to no avail.. since no one is on the other side anymore.
There is also the possibility of a customized Node Error Program. I am supplying a link for why a Node Error Program might be used. http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=/com.ib m.cics.ts31.doc/dfha3/dfha357.htm Rob Schramm And special thanks to a Mr. Eades -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Mason Sent: Friday, February 18, 2011 10:29 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Help with ADJSSCP George I know I have a response outstanding regarding your "keep-alive" problem, but I just spotted this. I seem to be the only list contributor dealing with VTAM matters so I don't expect I'm taking the pleasure away from anyone else by trying to deal with it immediately - although I'd be delighted to know that I was - and all are invited to try to work out what I may be meaning with that! - Actually the first point that comes to mind is why are you asking this question because anyone who has been through usual VTAM subarea networking education and worked with it should know all about the famous 087D sense code, its various modifiers ands and IST663I messages and what they imply. This reeks to me of a "let go" where the "suits" have decided that their VTAM systems programmer was "superfluous to requirements" and has been allowed to spend all his time on the golf course or supporting the football team at away matches - or equivalent pursuits for a lady. - Now looking at the names of the LUs in this failed session setup, I see that the origin LU (OLU) is FLANWR41.CICSPRDT which looks like a CICS system and the destination LU (DLU) is one of your TN3270 APPL statements (for external users), FLANWR41.TELNE21E This implies that CICS is trying to initiate a session with the TN3270 APPL statement which is *not* usual. Usually, it is the TN3270 APPL statement which is trying to initiate a session with CICS. Note the message IST264I REQUIRED ADJSSCP TABLE UNDEFINED which, in conjunction with the IST663I message with sense code 087D0002, is saying that, the SSCP (VTAM) has a session setup request from an OLU destined for a DLU which can't be satisfied in the "home" domain - because the required DLU is not defined - or is inactive. Thus it needs to send the session setup request to other, "away", SSCPs (also known in this context as CDRMs) (VTAMs) and, to do this, it sends the request sequentially following the order defined by the "adjacent SSCP" table defined for the DLU, which, if it doesn't already exist, can be a default list for the "home" network, as defined by the "network identifier" (NETID) - assuming we don't have an SNI configuration, which in this case we don't since the NETIDs are the same. However, you don't have a suitable "home" network adjacent SSCP table available maybe because you haven't actually got any other, "away", systems running VTAM connected with subarea links to your "home" system which can be used to build a dynamic adjacent SSCP list under control of the DYNASSCP start option specified as DYNASSCP=YES, the default. All of which is consistent with the messages you see - assuming two things: 1. TELNE21E is not active 2. You have specified, perhaps by default, the DUPDEFS start option as DUPDEFS=APPL or DUPDEFS=ALL, the default. I had a look at the explanation of the DUPDEFS start option and there is a bit of a confusing comment under DUPDEFS=APPL. I think this means that what I have described is likely to be valid only because you have defined your TN3270 APPL statements as a *model* APPL statement - which, because of your other thread, still ongoing, I know is as follows: TN3270A VBUILD TYPE=APPL TN3270G GROUP EAS=1 TELNI??? APPL TELNE??? APPL Well, as it should be now after my previous comments! I think this means that the DUPDEFS start option is then irrelevant since the LU name corresponding to the APPL statement is "known" only when it is active - which leaves only 1 from above. Perhaps you can explain what is causing this session setup attempt, which, as I said, looks odd and we can take it from there. Chris Mason On Fri, 18 Feb 2011 09:09:23 -0500, George Rodriguez <george.rodrig...@palmbeachschools.org> wrote: >I've got this message on SYSLOG and I've read several IBM publications >to try and understand, but none of the pubs explain how to solve a >particular problem. If I understood the problem, then I can take action >in resolving it. Here are the messages I get on SYSLOG: > >IST663I INIT OTHER REQUEST FAILED , SENSE=087D0002 >IST664I REAL OLU=FLANWR41.CICSPRDT ALIAS DLU=FLANWR41.TELNE21E >IST889I SID = D60BACEC2F856D69 >IST264I REQUIRED ADJSSCP TABLE UNDEFINED >IST314I END > >I've looked up the sense code (087D0002): > >087D Session services path error: A session-services request cannot > be rerouted along a path of SSCP-SSCP sessions. This > capability is required, for example, to set up a cross-network > LU-LU session. > >0002 An SSCP is unable to reroute a session services > request because a necessary routing table is not > available. This means that there is no adjacent > SSCP table corresponding to the rerouting key in the > resource identifier control vector. The receiver of > this value will, if possible, try rerouting to > another SSCP. > > VTAM Information: When VTAM receives this sense code > for a session initiation, it continues searching > through the adjacent SSCP table until the > destination LU is found or routing is exhausted. > >I just don't how to take the information from the message and do what's >needed to eliminate the problem. Can any of you great MVS ListServers >help me out? > >Thanks in advance... > >*George Rodriguez* ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
