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 that you need only have the application initiate the session and APPN and dynamic functions within VTAM will do the rest. There is also the matter of whence VTAM will obtain the operand values for a dynamically created CDRSC statement. As in the case of the dynamically created ADJCP statement, the defaults will get you started. You may find later that you need to "tweak" some parameters in order to improve performance but probably there will be unnecessary. It's handy to know in passing that again there is a start option which is the specification of "last resort", namely the ALSREQ start option, but here the VTAM developers have kindly provided the liberal default value NO. - Now you asked how you should define CICS in order to have the session established. There was a time when I could have helped you here but it has long gone. It may be sufficient to mention that, now you have established the necessary network infrastructure, you need only regard the problem within CICS as the initiation of an APPC (LU type 6.2) session from one CICS system to another. What connects the two systems is of no significance whatsoever. The two LU names involved, when fully-qualified, happen to have different NetIds but I do not believe CICS is the least bit interested in what that entails in terms of network infrastructure You may get help in this list over how to set up an APPC session between two CICS systems. If you don't get help here and, now that you know the network infrastructure is irrelevant, you still need help, you could try asking in the CICS list: http://listserv.uga.edu/cgi-bin/wa?SUBED1=cics-l&A=1 Chris Mason [1] If you want to know more about why you might want to do this, please post again. On Thu, 3 Dec 2009 03:10:25 -0600, Munif Sadek <[email protected]> wrote: >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 [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
