Dave
Somehow I missed your response to my first post in this thread which must
make my follow-up post look rather odd.
I'm using Google Groups in order to check and actually I can't see my
follow-up post - so who knows what's going on?[1] Then I did find it but not
"attached" to the thread - for some reason. Eventually I discovered you must
have "appended" your original post to a thread concerned with "DASD
Status" - confusion worse confounded.
If APPN's route selection has somehow decided that the "least weight"
route - bearing in mind that a route that is inoperative has infinite
weight - is the alternative route which follows the route of your
concatenation of CP to CP sessions, then you will get the result you
observed. There will be no need to define a dynamic adjacent link station
and so the ISTDSWMN major node will not need to be created.
As you correctly said, we need to work out why the route over the global
connection network, using the global virtual routing node NETIP.GCN1, is
*not* selected on your side.
I think what your original post implied was that, when your business partner
in NETC tried the APING test, they apparently did attempt to use the global
connection network (and failed?).
One test you could try - as I suggested so it's not new - is to code up the
switched resources and so use static definitions. You can then try the
global connection network in parallel.
As you are obviously aware, you need to be in control of your COS weights to
do this reliably. If you use the same transmission group characteristics -
or, in COS terms, effectively the same transmission group characteristics -
then it's the toss of a coin over which route, a truly direct route or a
route over the global virtual routing node, is selected. This is because
when a connection network is used - and I can't imagine why the rules should
be changed for this new (to me) thing, a *global* connection network - the
weight attributed to the virtual node is zero and the weights of the two
transmission groups added together is divided by two. Thus the weights for
the two routes will be the same for the, effectively the same, transmission
group characteristics.
You already use the EEXTCAMP set of characteristics for the links to the
virtual routing node. If in the test switched definitions you use EEXTWAN,
for example, I'm pretty sure - without actually scanning my COS table
exercise documentation - that you are bound to get a higher weight. Thus the
route over the virtual routing node should be preferred.
The only other suggestion I have is to scan section 3.3.4.4.4, "Traversing
multiple APPN network boundaries" in z/OS V1R8.0 Communications Server SNA
Network Implementation Guide in order to be sure you are obeying all the
rules.
You might like to ask your local friendly IBMer what wishy-washy language
such as "under certain circumstances" is supposed to mean. Perhaps the wind
needs to be blowing in the right direction.
There must be some lack of symmetry in the session paths which causes the
global connection network to be rejected as a possible route when tried from
your side but not when tried from the other side. And then there must be
some reason that it doesn't work when the attempt from the other side does
try to use the global connection network.
I'm sorry not to be of more help.
Chris Mason
[1] Incidentally Google Groups seems to have given up completely on
IBMTCP-L - since October 10th.
---
I am responding to the following "lost" post from Fri, Oct 27 2006 8:41 pm:
<quote>
Chris, let me explain a bit further.
Yes my d net,aping is successful to the distant EE VTAM in NETC. I see a
CNR***** RTP pipe is built and the results from the aping.
However the APING is traversing over my direct EE link with the middle
network I'll call NETB. We want the APING to use the GCN instead. We have
verified the weights are indeed less than the direct EE link, so there
should be no reason to NOT use the GCN.
My NETA (EE)--------NETB (EE)--------NETC (EE)
A D NET,MAJNODES does not list an ISTDSWMN.
My XCA in NETA's VTAMC is:
EEXCA VBUILD TYPE=XCA
EEPORT PORT MEDIUM=HPRIP,
IPPORT=12000,
IPTOS=(20,40,80,C0,C0),
LIVTIME=15,
SRQTIME=15,
SRQRETRY=9,
TIMER=60
EEGRPC GROUP DIAL=YES,ANSWER=ON,CALL=INOUT,
AUTOGEN=(20,EEC,X),
DYNPU=NO
EEGRPCB GROUP DIAL=YES,ANSWER=ON,CALL=INOUT,
CAPACITY=7M,
DYNPU=YES,
HOSTNAME=CPUC.NETA.COM,
TGP=EEXTCAMP,
UNRCHTIM=0,
VNNAME=NETIP.GCN1,
VNTYPE=GLOBAL,
AUTOGEN=(128,KXXGV,PXXGV)
The XCA in NETC's VTAM08
XCAEEM VBUILD TYPE=XCA
EEPORT PORT MEDIUM=HPRIP, C
LIVTIME=10, C
IPPORT=12000, C
IPTOS=(20,40,80,C0,C0), C
SRQTIME=15, C
SRQRETRY=6
EEGROUP GROUP ANSWER=ON,CALL=INOUT,DIAL=YES,ISTATUS=ACTIVE, C
AUTOGEN=(20,LEE,PEE),DYNPU=YES
GRPBNGCN GROUP ANSWER=ON,CALL=INOUT,DIAL=YES,ISTATUS=ACTIVE,
HOSTNAME=CPUX.NETC.COM,
VNNAME=NETIP.GCN1, VIRTUAL NETWORK NODE
VNTYPE=GLOBAL, GLOBAL VRN (VS LOCAL)
DYNPU=YES, ALLOW DYNAMIC PUS
TGP=EEXTCAMP,
CAPACITY=9M,
UNRCHTIM=0,
AUTOGEN=(128,L08GV,P08GV)
Dave Kutz
</quote>
----- 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 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
