Dave I've tried to compensate for my lack of experience with Enterprise Extender global connection networks by doing some reading. In "z/OS V1R8.0 Communications Server SNA Network Implementation Guide" there is a "new" chapter, "| 3.3 Chapter 6. Using Enterprise Extender (EE)". As you see I've "copied" the revision bar. It's only "new" insofar as it has been rewritten since I see that there is an identical chapter in the "z/OS V1R*7*.0 Communications Server SNA Network Implementation Guide". Perhaps the complete revision was to help make it easier to understand. If only, however, the author actually understood what he/she was writing about, it wouldn't be necessary to "read between the lines" so much and so many elementary stupidities could be avoided. But let's be grateful for what we got.
I'm assuming your configuration is a network node in your network, network A, connected to a network node in a common network, network X, presumably AGNS, connected to a network node in the business partner network, network B. Given that you can use Enterprise Extender for all connections, barring some problem with overloading, I expect that there is only one network node in the common network - not that it should matter whether there is one or there are many. I expect it's likely that all the network nodes are VTAM running extended border node (EBN) function. This last point may matter because there are some dark hints about the EBN in the PLU network needing to have defined the global virtual routing node (GVRN).I got that point from section 3.3.4.4.4, "Traversing multiple APPN network boundaries". One "rule" struck me as very, very odd and surely must be mistaken. Supposedly intermediate subnetworks on the path required for a global connection network cannot define any global connection networks!!! Amazing. <quote> - A GVRN is not used in intermediate subnetworks along a session setup path (except, possibly, as a local VRN). </quote> Maybe they mean that a *particular* GVRN cannot be used for sessions which traverse an APPN topology subnet and for sessions where a session endpoint lies in that intermediate APPN topology subnetwork. But who knows? If this is so it would seem that all global VRN names in use in network X to any of the external served networks such as networks A and B need to be known by the administrators of networks such as networks A and B so that those names can be avoided as the names of global VRNs to be used to communicate between networks such as networks A and B. Perhaps this is where a naming convention imposed by network X needs to come into play. It's actually an issue as to what a good naming convention for GVRNs might be. Should the NetID be that of one of the networks where the participating partner nodes reside? Perhaps the NetID should be that of one of the intermediate network, network X in the scheme described above. You have already had a suggestion - the post from Cynthia Davis - that one of the security provisions in the IP network may be your downfall. It may be that your business partner has managed to get through the session setup, has progressed further and hence the dynamic link setup has started: the appearance of the CNVxxxxx dynamic adjacent link station (implemented via the control blocks associated with a PU definition) name. It appears that, starting from your side, not even the session setup works, hence there is no attempt to define a dynamic adjacent link station. I appreciate you already have an Enterprise Extender connection working over at least one EBN but I'll go though the necessary steps which should apply both to you and your business partner. You have enabled your VTAM to support APPN - which also, in effect, covers HPR. You have some experience of defining and using connection networks and virtual routing nodes - probably with a LAN. You have basic experience setting up a connection to at least an adjacent APPN topology subnetwork using an EBN. Of course, it may be that the EBN lies only in the adjacent APPN topology subnetwork, AGNS. Here's a "rule" from section 3.3.4.4.4, "Traversing multiple APPN network boundaries" which *may* be important if this is your first Enterprise Extender global connection network: <quote> ... every subnetwork boundary along the session setup path is an extended subnetwork boundary. (That is, there is an EBN on *both* sides of every subnetwork boundary.) Each of the EBNs on the session setup path must be z/OS V1R2 Communications Server or later VTAMs. </quote> My asterisks around the word "both". There's may be a requirement that is very poorly explained in section 3.3.4.4.4 which is that, if the origin node and/or the destination node is not the EBN supporting the session setup in the same APPN topology subnetwork, then it needs to have the GVRN defined to it. This seems unlikely since you will normally, I expect, define all you connections as "single hop" with Enterprise Extender. The words "certain circumstances" always reveal a technical "cop-out". I can see vaguely why the EBNs might need to know that a VRN was a GVRN since they have to play charades in the session setup process and this knowledge may somehow assist the presumably tricky session setup required when it concerns using a GVRN. It seems unlikely that you don't have a concatenation of CP to CP sessions available in order to support the session setup process. If my suggested configuration applies I'm sure you will have. Just about the last topic that I can think of that may give you trouble is if you use routers performing a Network Address Translation (NAT) function. There seems to be massive encouragement to use HOSTNAME rather than IPADDR and so you need to be sure that the HOSTNAME resolves to a suitable address. Unless the NAT function is cleverer than I give it credit the resolution of HOSTNAME for a local node will need to be different from the resolution of the same HOSTNAME for the partner node. Probably some checking using NSLOOKUP is in order to be sure that addresses are passing though the NAT function as expected - from both sides. It may become a standard feature of testing Enterprise Extender global connection networks that at least the first attempted use of the facility involves testing with static definitions in order to minimise the number of additional features brought into play when establishing the connection when finally the dynamic connection is attempted. There's a strong hint in there somewhere. <g> Of course, once you've got the pattern sorted out, you can confidently simply invite more partner sites to use the same GVRN without the static definition testing - otherwise there's no point in the GVRN! I hope you are making full use of the VTAM DISPLAY commands specifically for use with Enterprise Extender which were new to me before I started on my research. Another testing idea I had based on the fact that a GVRN can behave just like a local VRN - and - very tantalisingly, "platforms" other than VTAM *may* be able to support Enterprise Extender global connection networks: >From section 3.3.4.3, "Contrasting local and global networks": <quote> Tip: Some products do not provide a choice between local and global connection networks. In general, if a product supports global connection networks but does not provide a choice of local or global (as part of connection network definition), then any connection networks that are defined are considered global. </quote> Thus you could try defining Enterprise Extender in a PC with Communications Server for Windows or Linux or an RS/6000 with Communications Server for AIX, configure the same VRN and APING test a connection to both your VTAM and your business partner's VTAM. Of course, you'd need to define a static connection with CP to CP sessions to your EBN and, if possible, your business partner's EBN. Here I'm relying on the likelihood that the other IBM Communications Server products fall into the category of product which "supports global connection networks but does not provide a choice of local or global (as part of connection network definition)". Let us know how you get on. If you still have problems, please post not only the XCA definitions but also a description of the configuration indicating the EBNs involved. You say you also passed switched definitions to IBM for scrutiny but I'm wondering why you had any since the objective is to use a GVRN after all. Perhaps you have some model definitions with DYNTYPE=VN. Incidentally, I'm pretty sure I know why you didn't get any joy out of IBM when you asked them for help. Chris Mason ----- Original Message ----- From: "Dave Kutz" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Friday, 27 October, 2006 1:38 PM Subject: VTAM and GCN > I am not sure if this list supports VTAM questions or not. If not, please > ignore and sorry. > > But if it does, I am trying to setup a Global Connection Network across an > EE-EE connection with a distant network. > The distant side when they do a D NET,APING to my VTAM, they are able to > attempt to create a dynamic PU based on following messages. > IST1576I DYNAMIC SWITCHED MAJOR NODE ISTDSWMN CREATED > They see messages with the CNV...... PU also. > > But when I do an APING back to their VTAM, I don't see any messages about > creating this CNV... dynamic PU. > > I verified my VTAM XCA and SWMN with IBM, but they don't see anything > incorrect. > > I was wondering if someone that has setup a GCN could provide some insight > where to look. I'm not even sure if the problem is my VTAM, the remote > VTAM, or the network in between that we both connect to in order to reach > each other. > > > Dave Kutz ---------------------------------------------------------------------- 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
