Chris, Were you suggesting that I code GWSSCP=YES on the NN? The documentation states that GWSSCP is forced to NO if the node is an EN.
I've been looking at the Session Management Exit and may try it out to see if it can translate the NETID. Luke -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Chris Mason Sent: Monday, December 28, 2009 4:22 PM To: [email protected] Subject: Re: VTAM search/routing problem Luke So it seems I have forgotten how to convert a non-network qualified - to use the terminology of the Communications Server (CS) SNA Resource Definition Reference manual - LU name into a network qualified LU name. Having a network qualified destination LU name is the key to being able to distinguish one route over topology subnetwork borders over another route in the Border Node. I used to teach SNI but unfortunately I didn't retain the documents of the presentations I used to give for SNI - except one, the Alias application.[1] Well, I had a look at this and I found the following in the notes to setting up the *real* name for a destination LU (DLU): <quote> A Real Name and Real Network NETID can be provided by CDRSC definition specified under a NETID statement if there are no name conflicts. An Alias Name, using a CDRSC definition not specified under a NETID statement or dynamic, can be assumed to be a Real Name by the GWSSCP just before issuing the RNAA request, again, if there are no name conflicts. If there are name conflicts, either the ALIAS application or the Session Management Exit must be used. The attempt to discover the Real Name and Real Network NETID can be made either at a GW or GW-Capable SSCP on the OLU side of the network boundary or in a GWSSCP on the adjacent side of the network boundary. </quote> OLU = originating LU Note the "can be provided by CDRSC definition specified under a NETID statement". Maybe I haven't forgotten how to convert a non-network qualified LU name into a network qualified LU name! And now I'm about to get adventurous! In other words this is not what I know but what I may be able to read between the lines in the manual. Note the talk of GW or GW-capable SSCP. Let's have a look at the GWSSCP start option. <quote> GWSSCP start option ... Specifies that an SSCP can be a gateway SSCP. If you code GWSSCP, the SSCP can still process CDRSCs defined with the NETID operand. </quote> Note the "process CDRSCs defined with the NETID operand". Could it be that, if GWSSCP is not specified as YES, VTAM refuses to pay attention to CDRSC definitions with a NETID specified? Maybe you need to have "gateway" logic enabled in VTAM in order to be able to have the destination LU qualified by a NetId using the definition I gave before. Note that I'm not now quite sure about the NQNMODE operand so try it with and without and see if the display of the CDRSC gets network-qualified. In order to enable "gateway" logic, you will need to specify GWSSCP=YES and SACONNS=YES and, maybe, specify something for HOSTSA. I don't expect that will do any harm to anything else. What intrigues me about all of this is that, back in the days when I used to teach SNI, getting a Real NetId assigned was a "big deal". There must have been a way to do it and those notes in the Alias presentation just must be correct since this was such an important point. The "big deal" was having to persuade VTAM to decide what the Real NetId was so close to the network of the originating LU in the case where you wanted not to have to specify some definition to decide it - a CDRSC as I'm now pretty certain it must be/have been. Now with your border node configuration, the Real NetId is also being decided - somewhere. It might be interesting to track the destination LU in your business partner's network in your network, the intermediate network and the destination network in each of the VTAMs through which it passes in order to see with which NetId the LU is qualified at each stage. That would mean a display of that LU/CDRSC in each of the VTAMs. It's an important point in all of this - a point to which the NQNMODE operand relates - that an LU has an alias identity and a real identity, this being something permitted within the SNA search requests. I used to know all about this in SNI but maybe there's an interesting story also in the APPN border support which somehow passed me by. One reason it could have passed me by is that I didn't have the wit to experiment with destination LUs which were *not* network qualified when I was playing with APPN border nodes - shame on me! But this reminds me. I'd be interested to know whether the ADJCLUST definition I gave before works. You could check this with an APING test since you can give a network-qualified destination/target name. And you mentioned "controlling application". If it's an option you might initiate the session not from within your application but by specifying LOGAPPL=MYNET.MYAPPL on the CDRSC. As I said, we're in "sandbox" mode now! Chris Mason [1] I handed my SNI class - two weeks with other really interesting advanced VTAM topics! - to some colleagues who set up a one week SNI class - and I expanded the two weeks class to exclusively interesting VTAM topics plus fun stuff such as the 3708. However, I retained the Alias presentation for my class because - well - it was a bit complicated for my colleagues! This explains why I still have the presentation material. On Tue, 22 Dec 2009 08:45:47 -0600, Rabbe, Luke <[email protected]> wrote: >Chris > >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 > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Chris Mason >Sent: Tuesday, December 22, 2009 4:37 AM >To: [email protected] >Subject: Re: VTAM search/routing problem > >Luke > >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 > >On Mon, 21 Dec 2009 09:22:38 -0600, Rabbe, Luke ><[email protected]> wrote: > >>I'm having a difficulty with routing particular process' VTAM traffic and I >can't figure out how to make VTAM do what I want it to. >> >>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 [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- 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
