John > Is it possible to get contact information for your customer that successfully set this up?
There's no point. When I said "we", I was supporting the principle that it was a joint effort given that the nature of the engagement was "best efforts" rather than "performance". However I have been responsible for all the technical input to the project. Supersession was working before the project, it continued working as each VTAM was enhanced with fully considered APPN definitions and finally had subarea definitions removed. It lacks now only a final change of one VTAM in one of the production sysplexes from being a Network Node to an End Node which depends on some channel-to-channel definitions being put in place. So you see this has nothing to do with Supersession, which is SNA/VTAM business-as-usual, but everything to do with understanding the topic and planning - as I said before. Another reason my precise customer experience may not be suitable is that you are involved with retiring your 3745s whereas my customer had already done that and, when I came on the scene, has a rather untidy mix of subarea and APPN - the latter caused by having added a few more VTAMs to the subarea, now ICN, VTAMs. If something worked, fine, if not, "tant pis", they were lucky - that word again! - there were no showstoppers. > I would like to get our VTAM systems programmer to work with your customer if possible. I always find it better to talk directly to the person who is experiencing the problem. Shouldn't it be your "VTAM systems programmer" who is making the posts? > ... but now he is struggling with CL/Supersession. It might be best if each specific problem is presented, sense codes and all[1]. > Do you remember if you had to convert all the APPLIDs to use APPC=YES? This somewhat shatters the presumption that you - or your "VTAM systems programmer" - has the education necessary to undertake the task even of maintaining the current subarea network. I detect a case of precipitate [2] "letting go" here. The purpose of APPC=YES is to authorize the use of an API provided by VTAM which goes some way to implementing the functions which should be provided by a full implementation of LU type 6.2. In specific terms it enables the use of the APPCCMD macros which can be found documented in the Communications Server (CS) SNA Programmer's LU 6.2 Guide and CS SNA Programmer's LU 6.2 Reference. It would be wrong to say that there is no connection between LU 6.2 and APPN. Because of its ancestry APPN, more specifically Low Entry Networking (LEN) from which APPN evolved, is most comfortable with LU type 6.2 sessions but APPN has provision for LU types which are not LU type 6.2. APPN employs LU type 6.2 for the LU to LU sessions which APPN uses for the services it provides. You know you need to define APPC=YES when the documentation for the application says you need to use it. It will be because the application uses the VTAM APPCCMD API. You do not specify APPC=YES for any other reason. Also, in order to prevent another possible trap: you do not necessarily need to specify APPC=YES whenever you know an application uses LU type 6.2. The most famous example of an application subsystem which supports LU type 6.2 but does not use the APPCCMD API is CICS. In effect, the APPL statement for CICS uses the specification APPC=NO! I wondered if you could do any harm by specifying APPC=YES. Probably not. If APPC=YES is specified, the default value for the PARSESS operand changes. If I thought long and hard about this I might be able to work out that it could cause mischief. Incidentally, should you take a look at the table of contents in the CS SNA Programmer's LU 6.2 Guide manual, you'll find a section entitled "VTAM as a session manager". No, it's still got nothing to do with Supersession! > Since we didn't define anything in ISTAPNCP it can't locate the APPLID. This is probably the most obvious indication that neither you nor your "VTAM systems programmer" have prepared yourselves for the task of enabling APPN in your VTAMs. It is not for a user to define anything in ISTAPNCP. VTAM defines ISTAPNCP in the following terms, taken from the first "hit" for ISTAPNCP in the CS SNA Resource Definition Reference manual: <quote> ISTAPNCP is a generic representation for an APPN CDRM. </quote> What ISTAPNCP does is provide a placeholder where VTAM knows it should switch from using subarea session setup procedures in conjunction with other VTAMs in the subarea network to use APPN session setup procedures when routing the request which is used to initiate sessions, generally referred to as *searching*. If the attempt to set up the session starting from within what this VTAM views as the APPN network, the process can continue with additional other VTAMs in the subarea network. The SORDER start option is particularly important in determining where the ISTAPNCP placeholder is positioned in whatever list of other VTAMs in the subarea network is developed in order to support the session setup process. Clearly you can read on from here in the CS SNA Network Implementation Guide and the CS SNA Resource Definition Reference for the details. It's conceivable you may need extra help. If so, please post what you observe, especially as reported by the VTAM which owns the resource which is attempting to initiate the session. For example, a group of messages starting with IST663I and ending with IST314I can often be found. You should be aware of the following also with regard to ISTAPNCP from the CS SNA Network Implementation Guide: <quote> Resources automatically activated by VTAM Certain internally maintained resources are automatically activated by VTAM when the message VTAM INITIALIZATION COMPLETE is issued. These resources can be displayed, but cannot be activated or deactivated by an operator. The following resources are automatically activated: - ... - VTAMSEG application program major node: -- ... -- ISTAPNCP -- ... - ... </quote> You can ignore this manifestation of ISTAPNCP. Useful background which I think you probably need in order to prepare yourself for enabling APPN in VTAM is contained in the following two redbooks: http://www.redbooks.ibm.com/abstracts/sg244656.html http://www.redbooks.ibm.com/abstracts/sg245204.html I expect you - and your "VTAM systems programmer" - will need most of the first volume and maybe some of the second depending on how adventurous you become! Chris Mason [1] If that appears to have the echo of a well-known phrase, it's intentional! [2] I had another word in mind originally but, bearing in mind this is a public forum, for diplomatic reasons, I have watered it down! On Tue, 2 Jun 2009 09:23:52 -0700, John Au <[email protected]> wrote: >Chris, > >Thanks for confirming the compatibility of Supersession and APPN. Is it >possible to get contact information for your customer that successfully >set this up? I would like to get our VTAM systems programmer to work >with your customer if possible. I passed the information you provided >in setting up APPN/EE to him and he was able to get APPN working, but >now he is struggling with CL/Supersession. Any help you can provide >would be most appreciated. > >Regards, > >John Au > > > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[email protected]] On >Behalf Of Chris Mason >Sent: Monday, June 01, 2009 4:43 PM >To: [email protected] >Subject: Re: CL/Supersession and APPN > >John > >The customer with which I work from time to time uses Supersession. It >has >continued to work without any difficulties while we changed the >underlying >SNA architecture from subarea ("cross-domain") to APPN without any >difficulties whatsoever. > >Do you have any specific concerns? > >Incidentally, a systems programmer there has even researched using VTAM >generic resources with Supersession with success. We hope to put that >into >production in the near future all in support of the general objective of > >introducing redundancy in support of continuous availability. > >It's not down to luck but understanding and planning! > >Chris Mason > >On Mon, 1 Jun 2009 14:21:05 -0500, John Au <[email protected]> wrote: > >>We are trying to get CL/Supersession to work with APPN and not using >the >>VTAM Cross Domain facilities. We would like to phase out our Front end >>processor (3745). Has anyone had any luck doing this? ---------------------------------------------------------------------- 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
