Chris, thanks for trying to help. I will try and respond to you below each
of your questions or statements below.
Dave Kutz
"Chris Mason" <[EMAIL PROTECTED]>
Sent by: "IBM Mainframe Discussion List" <IBM-MAIN@BAMA.UA.EDU>
10/30/2006 10:44 PM
Please respond to
"IBM Mainframe Discussion List" <IBM-MAIN@BAMA.UA.EDU>
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.
A)yes network X is not AGNS, but similar type network. Yes, only 1 NN in
the common network and all 3 of us are EBN. In my network I have two EBNs
(redundancy) but same results from either one.
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.
A) I believe that to be true because the GVRN would be from my network and
the remote network(s).
<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.
A) the GVRN name is unique and both networks agreed on the name as coded
in our XCA Groups. It does not reflect our existing network ids, but is
truly unique.
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.
A) a "d net,aping" does work to the cpname in the remote network, only the
aping session does not traverse the GVRN as we want it to. The session is
using the EE tg of the middle network.
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.
A) we three networks are at least z/OS V1.6
</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.
A) I can successfully ping and nslookup the remote networks DNS name for
his CPname. He also can do likewise to my DNS name for my CPnames. I code
HOSTNAME in the GVRN group of the XCA major node. It points to a DNS name
which reflects my CPnames IP address. This DNS name is coded in all 3
network DNS servers. Same for coding of the remote network's DNS name for
his CPname IP address. Also firewall rules were coded to permit udp any
for ports 12000-12004 for the EBN ip addresses.
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!
A) yes this is our wish; as more companies become EE/EBN capable, they
will also join 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.
A) yes, have done 'd net,topo' and d net,ee,list=detail' commands.
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.
A) yes we defined and activated a model
MODELGCN VBUILD TYPE=MODEL
GCNPU PU DISCNT=NO,DYNTYPE=VN,PUTYPE=2
Incidentally, I'm pretty sure I know why you didn't get any joy out of IBM
when you asked them for help.
I plan on retesting this weekend. I want to add a //SYSTCPD DD card
(TCPDATA) to my VTAMs as recommended by IBM support.
In the CS SNA Network Implementation Guide:
1. Configure the resolver.
VTAM uses the TCP/IP system resolver to perform name-to-address
resolution. The system resolver, in general, first attempts to
resolve the name by the way of one or more nameservers
(as defined by resolver configuration statements).
If unsuccessful, the resolver then attempts to resolve the name
using a local host table, such as HOSTS.SITEINFO or ETC.IPNODES.
For more information about defining nameservers to the resolver,
refer to the z/OS Communications Server: IP Configuration Guide.
The search order for selecting the TCPIP.DATA file to use is
documented in z/OS Communications Server: IP Configuration Guide.
The concept of data set concatenation does not apply here. It is
recommended that you choose to use SYSTCPD for allocating the
TCPIP.DATA file. In this case, this statement must be included
in your VTAM start procedure.
If still unsuccessful the last painful resort is to gather VTAM traces and
dumps of VTAMs in each of the 3 networks coordinated at same time.
Chris Mason
----- Original Message -----
From: "Dave Kutz" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <IBM-MAIN@BAMA.UA.EDU>
Sent: Friday, 27 October, 2006 1:38 PM
Subject: VTAM and GCN
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.
----------------------------------------------------------------------
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
