Munif I can see now that you are trying to run your sessions both in a subarea environment, using SNI and an APPN environment. This is a bit dangerous! There used to be a VTAM developer who always used to warn customers from trying to run with subarea and APPN in parallel.
Since you say your side has BN=NO specified, I assume that the other side has BN=YES specified. That should mean your side appears as an APPN End Node to the other side. This is all far too complicated and, since it is probably not what you want, it's not worth trying to work out why your CICS to CICS session passes over the SNI configuration rather than your Enterprise Extender (EE) connection. Unless you have a particular reason to establish the APPN border node connection as one side with BN=YES and one with BN=NO, I suggest that both sides specify BN=YES. That means that the BNDYN, BNORD and SNVC start options come into play but the default values BNDYN=LIMITED, BNORD=PRIORITY and SNVC=3 can be used. That should mean that, if there is a session setup attempt using the APPN "side" of VTAM, it will be tried. The only thing that worries me is that the partner may be defined in the session setup request without being qualified by the NetId. I know that this is not a problem with SNI but I just can't recall what happens with APPN. It may be required. You should post again if a session setup via APPN still doesn't work and we'll try to figure out how to achieve qualification. - If you have SORDER=APPN, ISTAPNCP is automatically placed in the adjacent SSCP list associated with any CDRSC. That means that the ISTAPNCP entry you placed in the adjacent SSCP table is ignored.[1] Where the ISTAPNCP is automatically placed is a bit tricky - all caused by VTAM developers trying to be helpful but ending up being very confusing! Having a mixture of subarea, APPN and APPN border node searching could be enormously complicated. However, it can be simplified in your case by specifying SORDER=APPNFRST. That ensures that there is no chance of the subarea network being used for a search before the APPN "side" of VTAM is tried.[2] - The APPNCOS start option in your VTAM is probably irrelevant. The APPNCOS start option in the partner VTAM *may* be relevant. If there are actually session setup attempts using the APPN path which are rejected with the 80140002 sense code, there may be an explanation which involves the APPNCOS start option. This reminds me that you could be having session setup attempts using the APPN path which are rejected and then the session setup attempt is retried using the subarea path. If the session setup eventually fails you can see what happened in your VTAM log in IST663I messages. - If you want to test with just the CICS system but let all other session setup flow via the SNI configuration, you may want to look into using the ADJLIST operand of the CDRSC statement. If this could be useful and it's not clear how to use this function from the manuals, please post again. Otherwise if there are times you want to test the EE connection and times you want to run production as now using the SNI configuration, you can specify SORDER=APPNFRST when you want to test the EE connection and SORDER=SUBAREA when you want to run production as now. This can be done using the MODIFY VTAMOPTS command. - Incidentally, I think what you might be missing is VTAM education which, needless to say, I used to give! Chris Mason [1] An ISTAPNCP entry in an adjacent SSCP table is respected *only* when SORDER=ADJSSCP. [2] With SORDER=APPN, if the partner is defined in a CDRSC as being subordinate to a subarea CDRM whether defined or created dynamically by a past session, a new session setup will always follow the subarea path. On Tue, 8 Dec 2009 02:54:39 -0600, Munif Sadek <munif.sa...@gmail.com> wrote: >Thank Chris (Mason) > > >You are a living encyclopaedia. > >I was required another CDRSC entry to get it going. Now my next bigger >headache. we are migrating from old DDN link to enterprise extender and Other >party will not give *some new* applications (non production) to test it. As a >mainframer, i do not want to destroy something that has been working without >testing new links. > >I am testing it on one of the subarea to connect using EE link but as soon as i >acquire this connection it in CICS, the connection goes via cross domain SNI >link. >I have dynamically modified ADJSSCP, and ISTAPNCP is the first ADJCDRM. >The subarea in question is ICN , BN=NO and SORDER = APPN. APPNCOS is >NONE. > > >Is there anything I am missing or time to open an ETR? > >Thanks and best regards, Munif ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
