Chris, That is pretty dang cool. I guess I was on the right track.. but in the wrong lane. I agree with you... I do not think CICS is playing fair. I am wondering if this is a bug and that the behavior for CICS should be fully honoring the CREATESESS option of CREATESESS(NO). While trying to be helpful is usually a good thing, I think giving control to CICS system programmer that setup the TYPETERM would be more advantageous.
Rob Schramm -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Mason Sent: Sunday, February 20, 2011 11:28 PM To: IBM-MAIN@bama.ua.edu Subject: CICS Session Failure and Model APPL Statements for SLUs (Was: Help with ADJSSCP) George What you need to state in your initial post is the degree to which something matters. In the case of these IST663I message groups, it appears not really to matter since no end-user is noticing anything. Thus the problem is that there are potentially inconsequential messages which you do not understand, not that your end-users are unable to get their jobs done. You'll note I've changed the Subject since the problem has nothing to do with ADJSSCPs. - >...> Rob could not help. Quite on the contrary, Rob has helped a great deal! What Rob is suggesting is that, as a consequence of the way the CICS reacts to session failures, following a failure of the session between the CICS primary LU and the TN3270 secondary LU, CICS is attempting to, as it were, repair the damage, by re-establishing the session. Now that I have seen a full sequence of CICS messages at the time of the session failure and the attempt to restart the session, I can see that Rob's suggestion that the session setup originating in CICS is the result of a reaction to a session failure is correct. The key token in amongst the CICS messages is SIMLOGON. Here is an analysis of the sequence of events based on the messages you have posted. Note that I have adjusted the messages for better comprehension. Naturally I turned to the CICS "Messages" manual for one hopes complete clarification of the messages and it is the manual for "CICS Transaction Server for z/OS V3R1" in order to be using the latest I could find: CICS Transaction Server for z/OS, CICS Messages and Codes, Version 3 Release 1, GC34-6442-03 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DFHG4B03/ You first posted a "session started" message, 3461: > DFHZC3461 I 02/18/2011 08:24:06 > CICSPRDT E0AD CSNE Node TELNE0AD session started. > ((2) Module name: DFHZOPX) NQNAME E0AD,CSNE, 8:24:06,FLANWR41 TELNE0AD > TNADDR E0AD,CSNE, 8:24:06, 10.50.14.22:1327 This tells us that a session has started between primary LU CICSPRDT and secondary LU TELNE0AD and not too much else[1] - except that, being a session supported by a TELNET server which concatenates a TCP connection to an SNA session, the TELNET server has the option to pass the TELNET client IP address and port number to the primary LU application - including the possibility for the session to pass through a session manager from z/OS V1R12 but only because the API was finally "exposed" and assuming that the developers of the session manager logic wear their socks/stockings with suspenders. You then posted a sequence of error messages associated with the ending of the session: - > DFHZC3424 E 02/18/2011 14:40:06 > CICSPRDT E0AD CSNE Session failure. Session terminated immediately. > ((1) Module name: DFHZNSP) > NQNAME E0AD,CSNE,14:40:06,FLANWR41 TELNE0AD >From the message text we learn two interesting points: 1. The session may be recovered later by VTAM. 2. ..., use the sense data and any associated messages to investigate the reason for the failure. Actually there was no sense data which hints to me that it was an UNBIND with one of the "unplanned" codes that caused the session to be terminated rather than any other sort of disaster - although the UNBIND is entitled to carry sense codes with the X'FE' "type" code - which, if I was the TN3270E server program developer, I think I would have used for a session ended because of a "timeout" but, without a trace of some sort, such as NLDM, we won't know for sure what was used. - > DFHZC3437 I 02/18/2011 14:40:06 > CICSPRDT E0AD CSNE Node TELNE0AD action taken: CLSDST ABTASK ABSEND ABRECV SIMLOGON > ((1) Module name: DFHZNAC) This is the key message from the "ZNAC" module. CICS tries not to reinvent the wheel, so it puts together a collection of potential "actions" as subroutines and, using a table, invokes a selection of those "actions" based on the situation which needs to be handled. Those "actions" are identified in those codes, some of them corresponding to macro calls over the VTAM API. In this case the "actions" are as follows, CICS - cleans up any control blocks in VTAM associated with the session which has failed: CLSDST (a VTAM macro) - cleans up its representation of the task associated with the session I guess: ABTASK - cleans up any pending status associated with outbound traffic I guess: ABSEND - cleans up any pending status associated with inbound traffic I guess: ABRECV - requests its SSCP (VTAM) to attempt to (re)establish the session: SIMLOGON (a VTAM macro) We'll come back to that last one. - > DFHSN1200 02/18/2011 14:40:06 > CICSPRDT Signoff at netname TELNE0AD by user POLETIC is complete. 265 transactions entered with 2 errors. I guess cleaning up the task involves automatic invocation of the "signoff" program. - > DFHZC3462 I 02/18/2011 14:40:06 > CICSPRDT E0AD CSNE Node TELNE0AD session terminated. > ((2) Module name: DFHZCLS) > NQNAME E0AD,CSNE,14:40:06,FLANWR41 TELNE0AD I expect this message is associated with the CLSDST "action". - > DFHZC2405 E 02/18/2011 14:40:06 > CICSPRDT E0AD CSNE Node TELNE0AD not activated. VTAM RETURN CODE 1000 > ((6) Module name: DFHZSYX) The description of the message indicates that there could be sense data here and I would expect sense data to be associated with the termination of a call over the VTAM API with return code 16 (X'10'), reason code 0 (X'00'). I have every confidence that the VTAM API call in question is the SIMLOGON call. Are you sure you haven't inadvertently truncated this message and lost the sense code data? In any case I expect the sense code is 087D0002 corresponding to the VTAM session setup failure. It would be helpful if only to show how the events are tied together. In case you weren't aware of it, in addition to the sense codes, you can also find the explanation of the VTAM return codes and reason codes in the z/OS Communications Server IP and SNA Codes manual in Chapter 2, "Return codes for VTAM macroinstructions". For X'1000' (16, 0) the only part of the explanation which is relevant to this configuration and logic is "Logical unit not available", "You are attempting to establish a session with a logical unit that is not active." - > DFHZC3437 I 02/18/2011 14:40:06 > CICSPRDT E0AD CSNE Node TELNE0AD action taken: NOCREATE CLSDST ABTASK ABSEND ABRECV > ((1) Module name: DFHZNAC) This is also a general clean-up set of "actions". However it is in response to a failure to establish a session rather than the failure of a session which did hitherto exist and so there is no SIMLOGON "action" added. Rather there is an "action" "NOCREATE" which the sole reference in the "Customisation" manual hints, very reasonably, is "do nothing more". Generally it is the "Dante" set of "actions": "Abandon hope all ye who enter here"! - > DFHZC3462 I 02/18/2011 14:40:06 > CICSPRDT E0AD CSNE Node TELNE0AD session terminated. > ((2) Module name: DFHZCLS) > NQNAME E0AD,CSNE,14:40:06,FLANWR41 TELNE0AD Again, I expect this message is associated with the CLSDST "action". - > DFHZC5966 I 02/18/2011 14:40:06 > CICSPRDT DELETE started for TERMINAL ( E0AD) > (Module name: DFHBSTZ). Because the control blocks associated with the original session setup were created dynamically, the "autoinstall" function, once all hope has been abandoned over maintaining an association of the control blocks with an active session, the control blocks are freed, "deleted". - DFHZC6966 I 02/18/2011 14:40:06 CICSPRDT Autoinstall delete for terminal E0AD with netname TELNE0AD was successful. This merely confirms that something went right! - As far as I can tell from the fact that 1. The "Customisation" manual, CICS Transaction Server for z/OS, CICS Customization Guide, Version 3 Release 1, SC34-6429-04, says nothing about CREATESESS, YES or NO 2. The little snippet of coding of a "node error program" I found searching for SIMLOGON in the "Customisation" manual includes setting off the bit which causes the SIMLOGON "action" to be invoked[2] I conclude that the use of SIMLOGON in the circumstances where a session is lost is "de rigeur" for self-respecting error recovery - but - if a problem is likely to be caused such as, taking an obvious example, when you not only create the resources for a session dynamically in the primary logical unit program but you also arrange to create resources dynamically in the secondary LU program, it just won't work! In other words, if the secondary LU is lost from the VTAM name space - is not even an "inactive" LU - when the session ends for whatever reason as happens when the secondary LU is created dynamically from a model APPL statement, there is nothing that CICS can do in order to re-establish the session and trying to use the SIMLOGON call for that purpose is utterly pointless. However, CICS is making the entirely reasonable assumption based, as it were, on how it always used to be, that the secondary LU may still be available for a session - and "reachable" - and so it is worth a try for CICS to re-establish the session. Actually I'm going to jump in here with the observation that CICS ought *not* to be making the assumption that re-establishing the session is worth a try since it should be the responsibility of the underlying SNA products to keep a session active if it's at all possible and, if those products give up, it is not for CICS to assume that have made a mess! It is, in fact, rather presumptuous of CICS ever to try using the SIMLOGON "action" under the circumstances of a session failure. As for "CREATESESS", there are no "hits" for this token in the "Customisation" manual. I conclude it is a "red herring" but I would be very happy if it could be explained that CREATESESS(YES) was necessary for CICS to consider a SIMLOGON call a valid call to make - with appropriate references, of course, which really should attempt to explain why nothing is written in the most obvious place for this requirement to be mentioned. Further evidence *against* the need for CREATESESS(YES) to be present in the "terminal definition" is the fact that, in the set of TERMTYPE statements supplied by CICS which mainly seem to be for 3270 sessions of one type or another, *all* specify CREATESESS(NO). CREATESESS(NO) is also the default specification in the TERMTYPE definition and "No" is the CEDA panel default for CReatesess. Anyhow, I can ask the question: did you find CREATESESS(YES) applied to the CICS definitions used for the TN3270 sessions? There remains only what I found in a thread in the CICS-L list dating from May 2004, "Hary Poter WANTED for Auto-Acquire my terminal" where John Chase waxes lyrical on the matter and seems to set great store by CREATESESS. However it is clear then - as in fact in his contribution to this thread - that John wasn't/isn't incorporating TELNET considerations into his thinking. - There is a *quick* solution to the matter of preventing CICS from initiating or trying to initiate sessions. You can specify the VTAM definition which will prevent CICS being able to request VTAM to initiate a session. Note that this applies to *all* session initiation attempts which CICS might want to make and so you should do this *only* if there is no other need for your CICS system to initiate sessions. In other words you need to be clear what *all* the functions performed by your CICS system are so that you can evaluate the change and, if you are satisfied you will not "break" anything, do it. The APPL statement for your CICS application will be something like CICSPRDT APPL AUTH=ACQ,... You should either specify AUTH=NOACQ or remove that suboperand of the AUTH operand so that the default specification, NOACQ, is assumed. Just to be sure you understand what I have proposed and appreciating that you may be unfamiliar with VTAM definitions, I will show you how you can make the change If you now have CICSPRDT APPL AUTH=ACQ,... you should specify CICSPRDT APPL ... or CICSPRDT APPL AUTH=NOACQ,... If you now have CICSPRDT APPL AUTH=(ACQ,xxx,yyy,...),... you should specify CICSPRDT APPL AUTH=(xxx,yyy,...),... or CICSPRDT APPL AUTH=(NOACQ,xxx,yyy,...),... What this might do is simply cause your existing CICS messages to complain that they are forbidden to do what they wanted to do. It may be cleverer to persuade CICS not even to try. On the other hand, it may really not matter that these VTAM IST663I message groups appear although it will be a neater system if they can be persuaded not to appear and it may be an even neater system if CICS doesn't feel the need to complain that it cannot initiate sessions - assuming it will so complain! There is also a start option and APPL statement operand, SIRFMSG, which can be specified as SIRFMSG=NONE. That will suppress *all* occasions when VTAM might want to create messages to describe a session failure. You would need to be very confident that you would never need those messages for problem determination to use this option. So the options are as follows: 1. Ignore the IST663I message groups. 2. Suppress the IST663I message groups by adding SIRFMSG=NONE on the CICS APPL statement. 3. Ensure AUTH=NOACQ applies for the CICS APPL statement. 4. Construct a "node error program" - see the reference Rob provided - which will "switch off" the SIMLOGON "action". 5. Arrange matters so that, whatever TN3270E event it is that is happening, the APPL stays active. I'll have to think about that and check out the TN3270E program parameters which might allow this - and, of course, I invite any specialists taking an interest in this topic to assist. It may well not be possible so to arrange matters - but it may be. It would have been potentially a lot more effective if this whole discussion - and your other discussion - had been happening in the IBMTCP-L list which has a greater concentration of the right sort of specialists who actually have "playpen" systems to hand. - Note that your start options and configuration member list of names is, in principle, not relevant to this problem - although, who knows? I might spot something. I'll have a look through them and make a few comments in another post. Chris Mason [1] Incidentally, why there should ever be sense data associated with a successful session start completely and utterly beats me and raises the question of whether I know anything whatsoever at all about SNA!!! [2] 3.5.4.5 Coding for specific VTAM sense codes http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/DFHA3B04/3.5.4.5 <quote> Figure 27 shows how your NEP error processors could test for the presence of specific VTAM sense codes. TEST1 EQU * CLC TWASENSR(2),SNS1 SENSE CODE EQUAL TO NNNN BNE TEST2 NO, THEN NEXT TEST NI TWAOPT1,TWAOAF PRINT ACTION MESSAGES ONLY OI TWAOPT2,TWAOAS+TWAOAR+TWAOAT ABANDON SEND,RECEIVE AND TASK NI TWAOPT2,255-TWAOASM SET SIMLOGON OFF OI TWAOPT3,TWAOINT SET INTLOG NOW ALLOWED NI TWAOPT3,255-TWAONINT OR RESET NOINTLOG B END . . . SNS1 DC X'NNNN' </quote> On Fri, 18 Feb 2011 20:06:54 -0500, George Rodriguez <george.rodrig...@palmbeachschools.org> wrote: >I just checked. No there are no other messages... >* >* >*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 3:43 PM, Rob Schramm <rob.schr...@gmail.com> wrote: > >> George, >> >> Is there another message prior to the DFHZC3424 regarding TELNE0AD? >> >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On >> Behalf >> Of George Rodriguez >> Sent: Friday, February 18, 2011 3:20 PM >> To: IBM-MAIN@bama.ua.edu >> Subject: Re: Help with ADJSSCP >> >> Rob, >> >> After I sent you the reply, I realized that there's more. Here's the rest: >> >> DFHZC3424 E 02/18/2011 14:40:06 CICSPRDT E0AD CSNE Session failure. Session >> terminated immediately. ((1) Module name: DFHZNSP) >> NQNAME E0AD,CSNE,14:40:06,FLANWR41 TELNE0AD >> >> DFHZC3437 I 02/18/2011 14:40:06 CICSPRDT E0AD CSNE Node TELNE0AD action >> taken: CLSDST ABTASK ABSEND ABRECV SIMLOGON ((1) Module name: DFHZNAC) >> >> DFHSN1200 02/18/2011 14:40:06 CICSPRDT Signoff at netname TELNE0AD by user >> POLETIC is complete. 265 transactions entered with 2 errors. >> >> DFHZC3462 I 02/18/2011 14:40:06 CICSPRDT E0AD CSNE Node TELNE0AD session >> terminated. ((2) Module name: DFHZCLS) NQNAME >> E0AD,CSNE,14:40:06,FLANWR41 >> TELNE0AD >> DFHZC2405 E 02/18/2011 14:40:06 CICSPRDT E0AD CSNE Node TELNE0AD not >> activated. VTAM RETURN CODE 1000 ((6) Module name: DFHZSYX) >> >> DFHZC3437 I 02/18/2011 14:40:06 CICSPRDT E0AD CSNE Node TELNE0AD action >> taken: NOCREATE CLSDST ABTASK ABSEND ABRECV ((1) Module name: DFHZNAC) >> >> DFHZC3462 I 02/18/2011 14:40:06 CICSPRDT E0AD CSNE Node TELNE0AD session >> terminated. ((2) Module name: DFHZCLS) NQNAME >> E0AD,CSNE,14:40:06,FLANWR41 >> TELNE0AD >> DFHZC5966 I 02/18/2011 14:40:06 CICSPRDT DELETE started for TERMINAL ( >> E0AD) (Module name: DFHBSTZ). >> DFHZC6966 I 02/18/2011 14:40:06 CICSPRDT Autoinstall delete for terminal >> E0AD with netname TELNE0AD was successful. >> >> Sorry for missing those the first time... >> * >> * >> *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
