Lizette In terms of "any ideas" in dealing with what I would certainly characterise as a problem rather than an issue, you should follow the "golden rule" regarding SNA sense codes:
1. (Try to) determine the product which decided to describe a problem using that sense code. 2. Check the manual created by that product shop for a description of why the product uses that sense code. It is to be expected that the product will select an appropriate sense code to describe the problem but it's not guaranteed. While on the subject of general principles regarding SNA sense codes, it's probably worth mentioning that, whenever an SNA sense code appears in an SNA request unit it's not always there in order to describe a problem. Some sense codes have been provided in order to cater for unusual situations in an SNA data exchange so that an application can take a different course, possibly involving some sort of recovery action. An example is 082B which is intended to be used by a secondary LU 2 when the SSCP-LU session has been used while an LU-LU session is in progress. Returning to the matter in hand, let's try and follow the golden rule. Well, actually I'm not going to follow it exactly! This is mainly because I have the relevant VTAM manual to hand (CS IP and SNA Codes) rather than the CICS manuals and the the VTAM manual helps a lot with this problem! Under the description of 0821 we find the following: <quote> Sense code 0821 Session parameters not valid: Session parameters included on a BIND were not valid or not supported by the half-session whose activation was requested. The session parameters are usually obtained from the logmode table entry. Bytes 2 and 3 following the sense code contain sense-code-specific information. 0000 No specific code applies. VTAM hint: Possible causes of this error include, but are not limited to, the following: - Sessions cannot log on to CICS. If this problem occurs, the sense code is displayed in message IST663I, and request is CINIT. When running CICS with AUTO-INSTALLATION, the terminal definition in the terminal control table terminal entry (TCTTE) must match the VTAM LOGMODE definition statement for the device. See the information about common subarea network problems in z/OS Communications Server: SNA Diagnosis Vol 1, Techniques and Procedures for more information about this problem. - The PLU has rejected the BIND session parameters. - The cryptographic function referenced in the logmode table entry is not active in all SSCPs involved in establishing the session. </quote> The first "VTAM hint" covers, in fact, precisely the circumstance - together with the VTAM messages - you describe - except that the VTAM manual authors are clear that they consider it a problem! Also honesty forces me to point out that both the first and the second "VTAM hints" refer to the same circumstance. Taking a step back in order to describe the subarea SNA protocols involved here, let us consider the flows that make up a session setup as briefly as possible. The first flow is a CDINIT request unit (RU) flowing from the SSCP of the origin LU (OLU) to the SSCP of the destination LU (DLU). There is a response to the CDINIT RU from the DLU to the OLU. At this point in the protocol flow, the SSCP of the secondary LU (SLU) (as opposed to the primary LU (PLU)) determines the up-to-8 character name which is used to describe the "session parameters", the "mode name". In the VTAM which implements the SSCP of the SLU, the "mode name" is used in order to "look up" a set of "session parameters" intended to be carried in an eventual BIND request - and known as a "BIND image". The association of "mode name" to "BIND image" is implemented as a VTAM mode or logmode table. Thus an alternative way to refer to a "mode name" is a "mode table entry name" or "logmode table entry name". It is a frequently used case that the SLU is also the OLU and where a "network solicitor" product such as TPX is used implementing a relay service so that the SLU is a VTAM application. The "mode name" is determined according to the following hierarchy: 1. program customization 2. the DLOGMOD operand of the SLU APPL statement The "BIND image" is determined according to the following hierarchy (not comprehensive): 1. the named entry in the module identified by the MODETAB operand of the SLU APPL statement 2. if blank, the first entry in the module identified by the MODETAB operand of the SLU APPL statement 3. the named entry in the ISTINCLM module 4. if blank, the first entry in the ISTINCLM module The "BIND image" is now carried in a CDCINIT RU from the SSCP of the SLU to the SSCP of the PLU (and there will be a positive response to the CDCINIT RU). The SSCP of the PLU now passes the "BIND image" to the PLU in a CINIT RU, the very same CINIT you see described in the IST663I message. At this point the PLU examines the "BIND image" and can pass judgement on it. The product implementing the PLU logic is CICS and it seems you may be using the autoinstall function. When I used the autoinstall function long ago, I relied a lot on messages in some CICS log or other in order to help show where my "BIND image" (or (log)mode table entry) differed from the parameters I had set up in the sets of CICS model "terminal" definitions. I can't recall for sure but it would be very reasonable for CICS to have used the 0821 sense code in order to inform me that no match was possible. The 0821 sense code would be attached to the response to the CINIT RU as a negative response. Of course no actual BIND RU would be sent to the SLU from the PLU as would be the case if there had been a match and a TCTTE had been created dynamically within CICS using a model corresponding to the "BIND image" (corresponding to a named mode table entry). Note that another use of the sense code 0821 is possible when the SLU receives the BIND RU, disapproves of it and attaches the 0821 sense code to the negative response to the BIND RU returned to the PLU. There's another point which is very useful to appreciate regarding the programming logic which lies in the implementation of the PLU between the arrival of the CINIT RU and the sending of the BIND RU. The implementation of the PLU is quite entitled completely to ignore whatever is in the "BIND image" and create a set of session parameters for the BIND request completely uninformed by the offered "BIND image". As long as you don't need to set pacing values and you don't care about "class of service" (COS), you can get away with letting the selected mode table entry for the session be the first one in the ISTINCLM module. Except for one obscure bit, JES2 used to behave this way[1] and maybe still does. I believe that the CICS autoinstall function is the precise opposite of this potential behaviour in that it requires that the "BIND image" be exactly correct for the purposes of matching a the model "terminal" definitions. What's odd about your problem - as I will persist in characterising it - is that you imply all was working up to "at some point". This doesn't sit well with a mismatch between a CICS TCTTE model and a (log)mode table entry which is likely to go from "never worked" to "working all the time" once the match has been achieved. Checking Larry's observation, I believe he has concentrated on the sudden change of behaviour rather than paying attention to the sense code. Regarding you second post: Whatever userid could possibly apply to CICS will not come into play until you have established a session with CICS, in other words, there has been a successful exchange of a BIND RU and a positive response to the BIND RU so that you have the opportunity to use the CSSN transaction - or the world has moved on considerably since I used to exercise CICS. I wonder how you have managed to interpret what CA have told you as a "VTAM error". The support people for the TPX product - which appears to be a CA product these days - should have an understanding equivalent to what I have described above and so should not have been "fingering" VTAM. What you should be "looking for" are those messages from CICS indicating why the autoinstall is not working. I seem to remember from my autoinstall experience that it was a bit tricky to locate them at first (is there a specific log for the autoinstall function?). You will be able to see the RU data using the appropriate NetView Session Monitor (NLDM) trace data - not forgetting the CPIU option. You should get your VTAM/NetView specialist to help you here. Another pretty "golden rule" is that there is no point taking a trace if you don't know what you might be looking for. Ideally you take a trace when something isn't working in order to compare - at least in memory - with what a similar trace shows when things are working correctly. When support people ask for a trace it's because they have that relevant experience. In order to ensure that Pat's responses are aligned with mine, Pat means "BIND image" rather than BIND since, as you can see, it's the CINIT RU which contains the 0821 sense code in the response when the PLU is objecting. It's the case of the SLU objecting that causes the 0821 sense code to be carried by the response to the BIND RU. Chris Mason [1] Unlike RSCS when VM VTAM was firs introduced which caused massive confusion with some quite experienced people at the time of the VM VTAM introduction program. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
