Re: Vtam 0821 and LUs
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. 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
Vtam 0821 and LUs
I am having an issue with an application that is defined in TPX. At some point users are unable to logon and start to receive 0821 Sense code from VTAM. I am thinking I do not have a sufficient number of LUs for somethign in TPX but I am unable to discern what that area is. I have TPXGR defined with 1000 LUs which is more than sufficient for my users. In fact a D NET command shows all the the TPXGR LUs and more than 60% are conct and the rest have ACTIV sessions. IST663I CINIT REQUEST FAILED, SENSE=0821 364 IST664I REAL OLU=USSCEG01.TPXGR001 REAL DLU=USSCEG01.CICSPB IST889I SID = F6E3F2C462F4730F IST314I END Any ideas how to determine what I need to add? Lizette -- 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
Re: Vtam 0821 and LUs
NOTICE: All information in and attached to the e-mail(s) below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message (electronic, paper, or otherwise). Thank you. You might want to make sure that the LU is not still active in the other product. I have had problems on occassion where a user breaks their connection between TPX and CICS while a transaction is still running. CICS still has the LU active because of the transaction, but TPX thinks the LU is not being used. Larry Gray Large Systems Engineering Lowe's Companies 336-658-7944 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Lizette Koehler Sent: Tuesday, March 18, 2008 1:05 PM To: IBM-MAIN@bama.ua.edu Subject: Vtam 0821 and LUs I am having an issue with an application that is defined in TPX. At some point users are unable to logon and start to receive 0821 Sense code from VTAM. I am thinking I do not have a sufficient number of LUs for somethign in TPX but I am unable to discern what that area is. I have TPXGR defined with 1000 LUs which is more than sufficient for my users. In fact a D NET command shows all the the TPXGR LUs and more than 60% are conct and the rest have ACTIV sessions. IST663I CINIT REQUEST FAILED, SENSE=0821 364 IST664I REAL OLU=USSCEG01.TPXGR001 REAL DLU=USSCEG01.CICSPB IST889I SID = F6E3F2C462F4730F IST314I END Any ideas how to determine what I need to add? Lizette -- 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
Re: Vtam 0821 and LUs
On Tue, 18 Mar 2008 13:04:32 -0400, Lizette Koehler [EMAIL PROTECTED] wrote: I am having an issue with an application that is defined in TPX. At some point users are unable to logon and start to receive 0821 Sense code from VTAM. I am thinking I do not have a sufficient number of LUs for somethign in TPX but I am unable to discern what that area is. I have TPXGR defined with 1000 LUs which is more than sufficient for my users. In fact a D NET command shows all the the TPXGR LUs and more than 60% are conct and the rest have ACTIV sessions. ... It's unlikely that this is an issue with the number of dfined LUs ... at least not directly related. An application (like CICS) is supposed use 0821 to indicate incompatable session parameters - that it could not support the BIND parameters specified in the LOGMODE associated with the LU. It's a bit tricky with CICS because the CICS AutoInstall process may have some reason to pick a very specific set of acceptable session parameters. Or a hard coded terminal definition for the LU may specify sessions parameters those specific sessions parameters. Either way, they may be at odds with the LOGMODE for the TPX-provided LU. My very non-CICS centric view is that 0821 and 0801 sense codes can mean just about anything when coming from CICS. Luckily, there are usually CICS error messages that provide more info. Pat O'Keefe -- 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
Re: Vtam 0821 and LUs
Thanks for all the suggestions so far. I have been testing with my userid which never goes into CICS. So I do not think it is a left over terminal. Though I will be checking this out. I am not a true cics sysprog so am light in understanding TPX and the Autoinstall process. We have setup 1 definition in RDO for the TPXGROUP. I was told that this is like a model that autoinstall uses to create all terminal names. I have been working with CA but they say it is a vtam error. I understand that the 0821 is from VTAM but I believe it is coming from something that is happening between TPX and CICS logons. We have been using TPX for 1 year. We just cut off access to the other session manager and made everyone use TPX to access our applications. This is the only issue I have at this time. The 0821 for a handful of users. I am not seeing any additional error messages in CICS log that would help me understand this issue. I have run a TPX trace, but do not really understand what I am looking at or for. Lizette -- 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
Re: Vtam 0821 and LUs
On Tue, 18 Mar 2008 21:11:04 -0400, Lizette Koehler [EMAIL PROTECTED] wrote: ... I have been working with CA but they say it is a vtam error. I understand that the 0821 is from VTAM but I believe it is coming from something that is happening between TPX and CICS logons. ... The BIND reject with the 0821 sense is being issued by CICS. VTAM just reports it. The CA people are right that it is not (exactly) a TPX problem, but it is not a VTAM or CICS problem, either. We have TPX but I am not familiar enough with it to know if/how it sets a LOGMODE name on the session request, or if it simply lets VTAM use the DLOGMOD parm on the VTAM APPL def for the LU name in question. However these session parameters are set, CICS does not like them. Hence the 0821. You need to find out what is being set, what CICS expects, and how to reconcile the 2. If there are no CICS messages being issues, you will have to work with your CICS gurus to see how to correct that. CICS can issue messages the give pretty good clues when it issues an 0821. I think it at least points to the byte in the BIND image that it doesn't like. Or if it is an Autoinstall problem, it can issue a message showing why it could not perform the install. ... This is the only issue I have at this time. The 0821 for a handful of users. I am not seeing any additional error messages in CICS log that would help me understand this issue. I have run a TPX trace, but do not really understand what I am looking at or for. ... I really don't think the TPX trace is going to show much. It may show the LOGMODE name and/or BIND image used inthe session request, but it is not going to say why CICS did not like it. Pat O'Keefe -- 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
