Re: VTAM - CICS definitions
Munif > Duh!!! my EE connection is still not working.. But you said it your first post that your Enterprise Extender (EE) connection was working and that it was supporting CP LU to CP LU sessions. I expect that what you mean is that you still haven't managed to cause your CICS LU to CICS LU session to use the EE connection as you reported in your second post. Having BN=YES on both sides should remove some possible complications. Again, I am obliged to assume that is the case since you haven't said so explicitly. If we are going to try to help you we will need more precision in descriptions, specifically confirmation of assumptions. In such a simple setup, you should not need specifically to create ADJCLUST tables. I think what I would like to see is the sense code generated when the ISTAPNCP entry in the adjacent SSCP list created for the other CICS CDRSC is tried and fails. I think this is going to require a test where you block the possibility of success over the SNI path by disabling that in some way. Just not having the NCP active would be a rather brutal way of doing it or you could simply deactivate the PU statement corresponding to the adjacent link station of the partner configuration in - I assume - your SNI "null" network. One point I left from the previous post is ensuring that the CDRSC for the CICS in the partner system is properly qualified. Perhaps you could post a display of that in order to be sure. It's important that we have confirmation that BN=YES is specified on both sides since, when BN=YES, the XNETALS start option, the default for the XNETALS operand of PU statements representing adjacent link stations, also assumes the YES value.[1] The XNETALS operand refers to some rather complicated options but is vital for setting up sessions where the NetId qualifying the LU name changes. The default value for the XNETALS start option is NO. Another point that is worrying me is that you made a point of mentioning that you were using Interchange Nodes (ICNs). Is this possibly a hint that the CICS systems are supported by VTAM subarea notes other than the ICNs? If so we will need a description of the configuration in terms of which nodes are involved and where the subarea and APPN paths are. Just to be equipped with what I hope is all possibly relevant information, you should post the following from both systems if you still need help: - selected start options SSCPNAME NETID NODETYPE HOSTSA SACONNS BN BNDYN BNORD SNVC ALSREQ CDRDYN CONNTYPE CPCP DYNADJCP DYNLU HPR SORDER SSCPDYN SSCPORD XNETALS - XCA major node for EE - switched major node PU statement for EE - model major node PU statement for EE if used - CDRSC statements for the involved CICS systems - configuration diagram unless just the two border node VTAMs are involved Incidentally, just because I mention a start option, it doesn't mean you should have coded it. It may well be that the default value is quite suitable. You should make sure in the VTAM log that no relevant start options have been rejected. If you need to preserve anonymity, you should substitute useful tokens for names you wish to conceal like the NETA, NETB, CICSA and CICSB you used in your first post. Chris Mason [1] Strangely enough I had remembered that the value of the XNETALS start option was forced to YES when BN=YES is specified but couldn't find any confirmation in the Communications Server (CS) SNA Resource Definition Reference manual - which had me worried for a while since I could see this as a reason for the effects you observed. A thorough search revealed the following in the CS SNA Network Implementation Guide of all places! When BN=YES is coded, XNETALS=YES is the default start option. When BN=YES is not coded, XNETALS=NO is the default start option. This is from Appendix I. Border node connection types, Table 70. Connection type for selected VTAM and partner node combinations. In fact, I see that, when during XID exchange, the NetIds are not the same, an APPN node will assume XNETALS=YES for that adjacent link station as long as XNETALS=NO has not been specified. This is - I hope - an accurate version of the poorly expressed note just prior to the note quoted above - and also confirmed something I had a niggling suspicion was the case. This would mean that, as it happens, what is specified for BN in your case is not relevant. On Mon, 14 Dec 2009 02:55:58 -0600, Munif Sadek wrote: >Duh!!! my EE connection is still not working.. > >Did change BN=YES. dfined new ADJCLUST for the remote network on this >gateway SSCP. > >on displaying ADJCLUST >IST2207I DEFINED TABLE FOR remote_network >IST2209I BNDYN = LIMITED FROM ADJCLUST TABLE >IST2208I BNORD = PRIORITY FROM START OPTION >IST1326I CP NAME TYPESTATE STATUS SNVC >IST1327I remote_network.cpnameDYNAMIC ACTIVE NOT SEARCHED >003 > > >anything i can
Re: VTAM - CICS definitions
Duh!!! my EE connection is still not working.. Did change BN=YES. dfined new ADJCLUST for the remote network on this gateway SSCP. on displaying ADJCLUST IST2207I DEFINED TABLE FOR remote_network IST2209I BNDYN = LIMITED FROM ADJCLUST TABLE IST2208I BNORD = PRIORITY FROM START OPTION IST1326I CP NAME TYPESTATE STATUS SNVC IST1327I remote_network.cpnameDYNAMIC ACTIVE NOT SEARCHED 003 anything i can do to change it.. regards Munif -- 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
Re: VTAM - CICS definitions
Munif I can see now that you are trying to run your sessions both in a subarea environment, using SNI and an APPN environment. This is a bit dangerous! There used to be a VTAM developer who always used to warn customers from trying to run with subarea and APPN in parallel. Since you say your side has BN=NO specified, I assume that the other side has BN=YES specified. That should mean your side appears as an APPN End Node to the other side. This is all far too complicated and, since it is probably not what you want, it's not worth trying to work out why your CICS to CICS session passes over the SNI configuration rather than your Enterprise Extender (EE) connection. Unless you have a particular reason to establish the APPN border node connection as one side with BN=YES and one with BN=NO, I suggest that both sides specify BN=YES. That means that the BNDYN, BNORD and SNVC start options come into play but the default values BNDYN=LIMITED, BNORD=PRIORITY and SNVC=3 can be used. That should mean that, if there is a session setup attempt using the APPN "side" of VTAM, it will be tried. The only thing that worries me is that the partner may be defined in the session setup request without being qualified by the NetId. I know that this is not a problem with SNI but I just can't recall what happens with APPN. It may be required. You should post again if a session setup via APPN still doesn't work and we'll try to figure out how to achieve qualification. - If you have SORDER=APPN, ISTAPNCP is automatically placed in the adjacent SSCP list associated with any CDRSC. That means that the ISTAPNCP entry you placed in the adjacent SSCP table is ignored.[1] Where the ISTAPNCP is automatically placed is a bit tricky - all caused by VTAM developers trying to be helpful but ending up being very confusing! Having a mixture of subarea, APPN and APPN border node searching could be enormously complicated. However, it can be simplified in your case by specifying SORDER=APPNFRST. That ensures that there is no chance of the subarea network being used for a search before the APPN "side" of VTAM is tried.[2] - The APPNCOS start option in your VTAM is probably irrelevant. The APPNCOS start option in the partner VTAM *may* be relevant. If there are actually session setup attempts using the APPN path which are rejected with the 80140002 sense code, there may be an explanation which involves the APPNCOS start option. This reminds me that you could be having session setup attempts using the APPN path which are rejected and then the session setup attempt is retried using the subarea path. If the session setup eventually fails you can see what happened in your VTAM log in IST663I messages. - If you want to test with just the CICS system but let all other session setup flow via the SNI configuration, you may want to look into using the ADJLIST operand of the CDRSC statement. If this could be useful and it's not clear how to use this function from the manuals, please post again. Otherwise if there are times you want to test the EE connection and times you want to run production as now using the SNI configuration, you can specify SORDER=APPNFRST when you want to test the EE connection and SORDER=SUBAREA when you want to run production as now. This can be done using the MODIFY VTAMOPTS command. - Incidentally, I think what you might be missing is VTAM education which, needless to say, I used to give! Chris Mason [1] An ISTAPNCP entry in an adjacent SSCP table is respected *only* when SORDER=ADJSSCP. [2] With SORDER=APPN, if the partner is defined in a CDRSC as being subordinate to a subarea CDRM whether defined or created dynamically by a past session, a new session setup will always follow the subarea path. On Tue, 8 Dec 2009 02:54:39 -0600, Munif Sadek wrote: >Thank Chris (Mason) > > >You are a living encyclopaedia. > >I was required another CDRSC entry to get it going. Now my next bigger >headache. we are migrating from old DDN link to enterprise extender and Other >party will not give *some new* applications (non production) to test it. As a >mainframer, i do not want to destroy something that has been working without >testing new links. > >I am testing it on one of the subarea to connect using EE link but as soon as i >acquire this connection it in CICS, the connection goes via cross domain SNI >link. >I have dynamically modified ADJSSCP, and ISTAPNCP is the first ADJCDRM. >The subarea in question is ICN , BN=NO and SORDER = APPN. APPNCOS is >NONE. > > >Is there anything I am missing or time to open an ETR? > >Thanks and best regards, Munif -- 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
Re: VTAM - CICS definitions
Thank Chris (Mason) You are a living encyclopaedia. I was required another CDRSC entry to get it going. Now my next bigger headache. we are migrating from old DDN link to enterprise extender and Other party will not give *some new* applications (non production) to test it. As a mainframer, i do not want to destroy something that has been working without testing new links. I am testing it on one of the subarea to connect using EE link but as soon as i acquire this connection it in CICS, the connection goes via cross domain SNI link. I have dynamically modified ADJSSCP, and ISTAPNCP is the first ADJCDRM. The subarea in question is ICN , BN=NO and SORDER = APPN. APPNCOS is NONE. Is there anything I am missing or time to open an ETR? Thanks and best regards, Munif -- 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
Re: VTAM - CICS definitions
Thanks Chris for the explanation. I know that cdrscs can either be dynamically created or explicitly defined but do not know anything about APPN. We have an ISC Link between 2 cics regions on 2 different lpars which pass thru a security product running on a 3rd lpar and I am still trying to figure out how to get them to work correctly when one side goes down and comes back up. The links seem to work fine during the day when we are here but somehow manage to misbehave on weekends and holidays when no one is around to fix them. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Mason Sent: Thursday, December 03, 2009 9:59 AM To: IBM-MAIN@bama.ua.edu Subject: Re: VTAM - CICS definitions Eileen >The network has to be able to find the remote CICS APPLIDs on each lpar so probably cdrsc definitions are needed on both sides. This is LEN-talk[1]! You been spending too much time around the Microsoft SNA products maybe! APPN has those handy CP LU to CP LU sessions which are there - among other things/functions - to provide a distributed directory - whatever the configuration. Thus VTAM A can find out all it will ever need to know about the LUs defined within VTAM B and vice versa. Actually, in one sense, you are quite correct, CDRSC definitions *are* needed on both sides - but they are created dynamically by VTAM. Chris Mason [1] LEN = Low Entry Networking On Thu, 3 Dec 2009 09:16:16 -0500, Barkow, Eileen wrote: >All CICS cares about is the NETNAME (APPLID of the remote CICS region) and a correct MODENAME pointing to a valid lu 6.2 logmode. >On the CONNECTION entry, just specify ACCESSMETHOD VTAM, protocol APPC. > >The network has to be able to find the remote CICS APPLIDs on each lpar so probably cdrsc definitions are needed on both sides. >I do not know about the rest of the network setup, but it seems to me that once the CICS applids are known on both sides of the link, >There should not be any problem connecting. > >-Original Message- >From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Munif Sadek >Sent: Thursday, December 03, 2009 4:10 AM >To: IBM-MAIN@bama.ua.edu >Subject: VTAM - CICS definitions > >Dear listers > >I have got CP - CP sessions going between two different mainframe networks, >lets say NETA.A and NETB.B using Enterprise extender, and now would like to >establish connectivity between two CICS - CICSA (running on NETA.A) and >CICSB(running on NETB.B). What do i need to define: > >A) do i have to create another PU on NETA.A for CICSB besides having a >switched major node of NETB.B > >B) What do i need to define in CEDA - CSD for CONneection and SESSion >parameters. It needs to be simple APPC LU6.2 connection. > >and yes both CPs are ICN nodes. > >your help or any pointer in the correct direction is much appreciated. > > >best regards >Munif -- 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
Re: VTAM - CICS definitions
Eileen >The network has to be able to find the remote CICS APPLIDs on each lpar so probably cdrsc definitions are needed on both sides. This is LEN-talk[1]! You been spending too much time around the Microsoft SNA products maybe! APPN has those handy CP LU to CP LU sessions which are there - among other things/functions - to provide a distributed directory - whatever the configuration. Thus VTAM A can find out all it will ever need to know about the LUs defined within VTAM B and vice versa. Actually, in one sense, you are quite correct, CDRSC definitions *are* needed on both sides - but they are created dynamically by VTAM. Chris Mason [1] LEN = Low Entry Networking On Thu, 3 Dec 2009 09:16:16 -0500, Barkow, Eileen wrote: >All CICS cares about is the NETNAME (APPLID of the remote CICS region) and a correct MODENAME pointing to a valid lu 6.2 logmode. >On the CONNECTION entry, just specify ACCESSMETHOD VTAM, protocol APPC. > >The network has to be able to find the remote CICS APPLIDs on each lpar so probably cdrsc definitions are needed on both sides. >I do not know about the rest of the network setup, but it seems to me that once the CICS applids are known on both sides of the link, >There should not be any problem connecting. > >-Original Message- >From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Munif Sadek >Sent: Thursday, December 03, 2009 4:10 AM >To: IBM-MAIN@bama.ua.edu >Subject: VTAM - CICS definitions > >Dear listers > >I have got CP - CP sessions going between two different mainframe networks, >lets say NETA.A and NETB.B using Enterprise extender, and now would like to >establish connectivity between two CICS - CICSA (running on NETA.A) and >CICSB(running on NETB.B). What do i need to define: > >A) do i have to create another PU on NETA.A for CICSB besides having a >switched major node of NETB.B > >B) What do i need to define in CEDA - CSD for CONneection and SESSion >parameters. It needs to be simple APPC LU6.2 connection. > >and yes both CPs are ICN nodes. > >your help or any pointer in the correct direction is much appreciated. > > >best regards >Munif -- 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
Re: VTAM - CICS definitions
Munif Let us restate - one hopes accurately - your configuration: You have a VTAM node with NETID=NETA and SSCPNAME=A and another VTAM node with NETID=NETB and SSCPNAME=B. Having created Enterprise Extender (EE) definitions successfully in both VTAMs, you have established a connection between both VTAMs and over this connection and there are CP LU to CP LU sessions using mode name CPSVCMG. This being VTAM, the CP LUs are - with the exception of the diagnostic APING transaction - limited to just these sessions and the LUs take the name given by the NETID and SSCPNAME start options. You have also told us that you have specified NODETYPE=NN - for Network Node - since the classification of the VTAM node is ICN, namely an Interchange Node. The fact that you have specified SACONNS=YES (or perhaps have not specified anything for the SACONNS start option but still have some subarea number specified as a value of the HOSTSA start option) is immaterial. Since the two VTAM nodes have different NetIds, they span a network border. Thus at least one of the VTAMs also has BN=YES as a start option. Despite the fact that you mention "two different mainframe networks", you do not mention any more VTAM systems, so I am assuming that these two VTAM systems are the only two systems which relate to this query. In fact it will change probably nothing if the VTAM systems supporting the CICS systems in which you are interested are not the VTAMs supporting the EE connection but VTAMs resident in the same SNA network of either a subarea or an APPN flavour. In order to create the connection between the two VTAM systems, you have set up an XCA major node in the VTAMLST data set of both VTAMs. You need to initiate the connection and so you must have created a Switched major node in one of the VTAMLST data sets containing a PU statement specifying the CP name of the partner node and a PATH statement specifying the IP address or name - as known to name servers in the IP network - of the partner node. In the other VTAMLST data set, you may have created another Switched major node containing minimally a PU statement specifying the CP name of the partner node - or - you may have specified DYNPU=YES in the GROUP statement in the XCA major node and have created a Model major node containing a PU statement with DYNTYPE=EE specified. Since you are using an EE connection, you must use APPN High Performance Routing (HPR) over the connection. This necessitates running a Rapid Transport Protocol (RTP) logical connection which incorporates the EE connection and, assuming your sessions are between the two VTAMs involved (or that the sessions are between other VTAMs but, for some odd reason, you have forced the RTP connection to be limited to the same VTAMs as support the EE connection), you may have added a PU statement with DYNTYPE=RTP to Model major nodes in one or both VTAMLST data sets.[1] So now we know what your configuration is and, specifically, what PU statements you need. - In order to create a session between an application, CICS or otherwise, in VTAM A and an application, CICS or otherwise, in VTAM B, you need rely only on definitions within the applications themselves. As far as VTAM is concerned, you can rely upon the dynamic creation of cross-domain resource (CDRSC) definitions in both VTAMs. In principle, you need to specify DYNLU=YES on the ADJCP statement which represents VTAM B in VTAM A and the ADJCP statement which represents VTAM A in VTAM B. ADJCP statements are defined within Adjacent Control Point major nodes (VBUILD TYPE=ADJCP). It is usual to rely upon VTAM to create ADJCP statements dynamically when contact is first made between VTAM and an adjacent APPN node (including a VTAM APPN node obviously). But whence is VTAM to obtain the operand values for the dynamically created ADJCP statement, most importantly the value of the DYNLU operand? The name of the statement is the contacted CP name. The value of the NETID operand is obtained from the qualifying NetId clearly. Other operands take default values which, in the case of a dynamically created ASDJCP statement means, for many operands, restrictions are not imposed. The all-important value of the DYNLU operand is obtained from the PU statement associated with this first contact between the APPN nodes. But what if the PU statement does not have the DYNLU operand specified - including the case of a PU statement itself being created dynamically because DYNPU=YES was specified on the appropriate definition statement, an XCA major node GROUP statement in the case of an EE connection? The DYNLU specification of "last resort" as it were is the DYNLU start option. But, beware, just letting definition values be specified by default stops here. The default value of the DYNLU start option is NO. If you want all the magic above to happen for you, you need to specify DYNLU=YES in the start options. I said above th
Re: VTAM - CICS definitions
All CICS cares about is the NETNAME (APPLID of the remote CICS region) and a correct MODENAME pointing to a valid lu 6.2 logmode. On the CONNECTION entry, just specify ACCESSMETHOD VTAM, protocol APPC. The network has to be able to find the remote CICS APPLIDs on each lpar so probably cdrsc definitions are needed on both sides. I do not know about the rest of the network setup, but it seems to me that once the CICS applids are known on both sides of the link, There should not be any problem connecting. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Munif Sadek Sent: Thursday, December 03, 2009 4:10 AM To: IBM-MAIN@bama.ua.edu Subject: VTAM - CICS definitions Dear listers I have got CP - CP sessions going between two different mainframe networks, lets say NETA.A and NETB.B using Enterprise extender, and now would like to establish connectivity between two CICS - CICSA (running on NETA.A) and CICSB(running on NETB.B). What do i need to define: A) do i have to create another PU on NETA.A for CICSB besides having a switched major node of NETB.B B) What do i need to define in CEDA - CSD for CONneection and SESSion parameters. It needs to be simple APPC LU6.2 connection. and yes both CPs are ICN nodes. your help or any pointer in the correct direction is much appreciated. best regards Munif -- 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
VTAM - CICS definitions
Dear listers I have got CP - CP sessions going between two different mainframe networks, lets say NETA.A and NETB.B using Enterprise extender, and now would like to establish connectivity between two CICS - CICSA (running on NETA.A) and CICSB(running on NETB.B). What do i need to define: A) do i have to create another PU on NETA.A for CICSB besides having a switched major node of NETB.B B) What do i need to define in CEDA - CSD for CONneection and SESSion parameters. It needs to be simple APPC LU6.2 connection. and yes both CPs are ICN nodes. your help or any pointer in the correct direction is much appreciated. best regards Munif -- 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
