Chris, There should be a message associated with the disconnect or termination. The last one was for the session start.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of George Rodriguez Sent: Friday, February 18, 2011 2:52 PM To: IBM-MAIN@bama.ua.edu Subject: Fwd: Help with ADJSSCP Hi Chris, Rob could not help. * * *George Rodriguez* *Specialist II - IT Solutions* *Application Support / Quality Assurance* *PX - 47652* *(561) 357-7652 (office)* *(561) 707-3496 (mobile)* *School District of Palm Beach County* *3348 Forest Hill Blvd.* *Room B-332* *West Palm Beach, FL. 33406-5869* *Florida's Only A-Rated Urban District For Six Consecutive Years* ---------- Forwarded message ---------- From: George Rodriguez <george.rodrig...@palmbeachschools.org> Date: Fri, Feb 18, 2011 at 1:45 PM Subject: Re: Help with ADJSSCP To: Rob Schramm <rob.schr...@gmail.com> Here you go: DFHZC6935 I 02/18/2011 08:24:06 CICSPRDT Autoinstall for terminal E0AD with netname TELNE0AD using model or template DFHLU2E2 successful. and when I looked at the TYPETERM(DFHLU2E2), this is that parm it has: CReatesess : No Thanks. . . * * *George Rodriguez* *Specialist II - IT Solutions* *Application Support / Quality Assurance* *PX - 47652* *(561) 357-7652 (office)* *(561) 707-3496 (mobile)* *School District of Palm Beach County* *3348 Forest Hill Blvd.* *Room B-332* *West Palm Beach, FL. 33406-5869* *Florida's Only A-Rated Urban District For Six Consecutive Years* On Fri, Feb 18, 2011 at 1:36 PM, Rob Schramm <rob.schr...@gmail.com> wrote: > George, > > Did you find the DFHZC6935I that indicates what TYPETERM was used > during the install of the terminal TELNE0AD? I would not necessarily > trust the GROUP definitions. The message is a better indicator of what is happening. > > Rob > > From: George Rodriguez [mailto:george.rodrig...@palmbeachschools.org] > Sent: Friday, February 18, 2011 1:27 PM > To: Rob Schramm > Subject: Re: Help with ADJSSCP > > From what I see in the CICS group definition, DFHTERM and DFHTYPE, > CREATESESS is set to NO. When I look at terminals in the TOR, this is > how it > looks: > > Ter(E0AD) Pri( 000 ) Pag Ins Ati Tti Loc > Net(TELNE0AD) Acq Nqn(FLANWR41.TELNE0AD) > > and in the CICS that's designated as the AOR, this is how it looks: > > Ter(E0AD) Pri( 000 ) Pag Ins Ati Tti Rte > Net(TELNE0AD) Rem(CITR) > > Thanks for the help... > > George Rodriguez > Specialist II - IT Solutions > Application Support / Quality Assurance PX - 47652 > (561) 357-7652 (office) > (561) 707-3496 (mobile) > School District of Palm Beach County > 3348 Forest Hill Blvd. > Room B-332 > West Palm Beach, FL. 33406-5869 > Florida's Only A-Rated Urban District For Six Consecutive Years > > > On Fri, Feb 18, 2011 at 12:19 PM, Rob Schramm <rob.schr...@gmail.com> > wrote: > Did you confirm that you have CREATESESS(YES) on the TYPETERM definition > that was used to install the terminal? > > From: George Rodriguez [mailto:george.rodrig...@palmbeachschools.org] > Sent: Friday, February 18, 2011 11:55 AM > To: IBM Mainframe Discussion List > Cc: Rob Schramm > Subject: Re: Help with ADJSSCP > > Rob, > > So if I remove the option CREATESESS(YES) from the TYPETERM definition, > would that resolve my problem? > > > George Rodriguez > Specialist II - IT Solutions > Application Support / Quality Assurance > PX - 47652 > (561) 357-7652 (office) > (561) 707-3496 (mobile) > School District of Palm Beach County > 3348 Forest Hill Blvd. > Room B-332 > West Palm Beach, FL. 33406-5869 > Florida's Only A-Rated Urban District For Six Consecutive Years > > On Fri, Feb 18, 2011 at 11:40 AM, Rob Schramm <rob.schr...@gmail.com> > wrote: > 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 > > Home of Florida's first LEED Gold Certified School > > Under Florida law, e-mail addresses are public records. If you do not want > your e-mail address > released in response to a public records request, do not send electronic > mail to this entity. > Instead, contact this office by phone or in writing. > > > Home of Florida's first LEED Gold Certified School > > Under Florida law, e-mail addresses are public records. If you do not want > your e-mail address > released in response to a public records request, do not send electronic > mail to this entity. > Instead, contact this office by phone or in writing. > > > Home of Florida's first LEED Gold Certified School Under Florida law, e-mail addresses are public records. If you do not want your e-mail address released in response to a public records request, do not send electronic mail to this entity. Instead, contact this office by phone or in writing. ---------------------------------------------------------------------- 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
