My network is 1 network node and several end nodes. The application in this process resides on an end node. I have 2 Enterprise Extender nodes on the network node. One EE node is connected to an intermediate network. The other is directly connected to a business partner's network. I used to use the intermediate network to reach the business partner's network, but now I only want traffic to flow through the direct route.
I'm able to accomplish this when the EE connection to the business parter (EEBP) is active and session initiation is attempted. When EEBP is active, the traffic flows from my end node, to my network node, through EEBP, and to the business partner's CP. That's great. However, if EEBP is made inactive, VTAM routes all new and existing sessions through the intermediate network. I don't want this to happen - I don't want to use the intermediate network any more.
These are my VTAM defintions that I think are relavant:
Network node:
Adjacent cluster table:
VBUILD TYPE=ADJCLUST
NETWORK NETID=(RMTNET)
RMTCP NEXTCP CPNAME=RMTNET.RMTCP,SNVC=2
NNCP NEXTCP CPNAME=MYNET.NNCP,SNVC=2
ADJSSCP table:
VBUILD TYPE=ADJSSCP
NETWORK NETID=RMTNET,SORDER=ADJSSCP
RMTCP ADJCDRM
End node:
VTAMOPT SORDER=APPNFRST
ADJSSCP table:
VBUILD TYPE=ADJSSCP
NETWORK NETID=RMTNET,SORDER=ADJSSCP
RMTCP ADJCDRM
NNCP ADJCDRM
VBUILD TYPE=ADJSSCP
NETWORK NETID=MYNET
NNCP ADJCDRM
ENCP1 ADJCDRM
ENCP2 ADJCDRM
ENCP3 ADJCDRM
NETWORK
NNCP ADJCDRM
ENCP1 ADJCDRM
ENCP2 ADJCDRM
ENCP3 ADJCDRM
My CDRSCs on the EN are dynamic. I don't think this matters because I tried this with statically defined CDRSCs and got the same result.
I suspect a clue to the problem lies in the fact that when the application attempts to start a session, the remote LU is qualified with my network ID as opposed to the business partner's network ID (MYNET.LU1 vs. RMTNET.LU1). So, the EN VTAM uses the ADJSSCP table for MYNET instead of RMTNET. In doing so the APPN network is searched first because of the VTAM startup option. And because of that the remote CP is found whether the direct EE connection is active or not. And when the direct EE connection is active, VTAM chooses to use it. I don't want to change my local network ADJSSCP table or the SORDER default on the end node.
I hope I've explained myself well enough. Does anyone have any ideas on how to establish and maintain the route through the direct EE connection?
Luke
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
> I have 2 Enterprise Extender nodes on the network node. One EE node is
connected to an intermediate network. The other is directly connected to a
business partner's network.
Terminology is a bit confused. EE constitutes a *connection* not a node.
> I used to use the intermediate network to reach the business partner's
network, but now I only want traffic to flow through the direct route.
> I'm able to accomplish this when the EE connection to the business porter
(EEBP) is active and session initiation is attempted. When EEBP is active, the
traffic flows from my end node, to my network node, through EEBP, and to the
business partner's CP. That's great. However, if EEBP is made inactive, VTAM
routes all new and existing sessions through the intermediate network. I don't
want this to happen - I don't want to use the intermediate network any more.
So, when the partner network is that of your business partner, you want to
use only the direct EE logical connection and not even try to start sessions
with your business partner when that EE logical connection is not functioning.
You could do this with COS. You could pretend that the transmission group
(TG)[1] to your business partner's network was secure to the level PUBLIC
and you would use an APPN mode #INTERSC or #BATCHSC for example which
requires a minimum SECURITY level of PUBLIC. You would also need to specify
a SECURITY level of PUBLIC on the TG between your End Node and your
Network Node.
By keeping the SECURITY level of the TG to the intermediate network as
UNSECURE[2] which I'll bet it is now as will be all your current TGs, you will
avoid using that TG.
Incidentally, as long as the entry ISTAPNCP appears in your adjacent SSCP
tables either explicitly or implicitly based on the SORDER start option, the rest
of it matters not at all - assuming there is no subarea path somewhere to your
business partner as there would be if you still had your SNI configuration in
place.
Of course, all that depends on your having SACONNS=YES, the default when
the HOSTSA start option is present. If you have SACONNS=NO or you force it
to NO by having removed the HOSTSA start option, then adjacent SSCP
tables are ignored.
Chris Mason
[1] The "architecture" name for a link.
[2] The poor lambs of APPN architects were orthographically challenged I'm
afraid or they would have known that the correct spelling was INSECURE!
I've taken another look at this because it should be possible to do what you
want by using an adjacent cluster routing list. So I did some research in order
to refresh my memory as best I could over how it all might work - but you'll
have to test it, of course.
First let's have a CDRSC so that we know what network identifier belongs to
the remote LU:
VBUILD TYPE=CDRSC
NETWORK NETID=RMTNET
RMTLU CDRSC NATIVE=NO,NQNMODE=NQNAME,REGISTER=YES,SUBAREA=NO
Note that REGISTER=YES is specified in case the partner LU initiates the
session sometimes.
This should be defined in the End Node which initiates the session. After
attempting the session initiation, you should display the LU name (as a
CDRSC) in the Network Node (Server) to be sure it is qualified with the desired
NETID.
You may need to clear the CDRSC out of the Network Node by using the
following command:
VARY NET,INACT,ID=RMTLU,DELETE=YES
Now let's set up the adjacent cluster routing list in the Network Node
(Server)/Border Node so that the session setup is forbidden to go anywhere
but where we want it to go:
VBUILD TYPE=ADJCLUST
NETWORK NETID=RMTNET
RMTCP NEXTCP
CPNAME=RMTNET.RMTCP,BNDYN=NONE,BNORD=DEFINED,SNVC=2
Note that BNORD=DEFINED is actually redundant given there is only one entry!
The way the subnetwork visit count (SNVC) works is a bit odd. It is something
like the following:
1. When the request is about to cross a subnetwork border, 1 is subtracted
from the SNVC value in the request.
2. If the value is now 0, the request is not sent. Obviously if it is now more
than 0, the request is sent.
That explains why SNVC=1 limits you to your native subnetwork and SNVC=2
allows just one subnetwork border to be crossed.
-
Well, I hope that's a starting point! Let us know how you get on.
Chris Mason
Thank you for the suggestions. I was able to active the CDRSC on the EN, delete the CDRSC from the NN, and update the ADJCLUST table entry. That all looks good and looks like it should probably work.
However, when the local application attempts to establish a session with the remote LU it is looking for MYNET.RMTLU as opposed to RMTNET.RMTLU. And since the new CDRSC was activated, that can't be resolved.
Do I need to be controlling application session request or is there something within VTAM that I can use to control either the request or the resolution?
Thank you
Luke