Munif > Duh!!! my EE connection is still not working..
But you said it your first post that your Enterprise Extender (EE) connection was working and that it was supporting CP LU to CP LU sessions. I expect that what you mean is that you still haven't managed to cause your CICS LU to CICS LU session to use the EE connection as you reported in your second post. Having BN=YES on both sides should remove some possible complications. Again, I am obliged to assume that is the case since you haven't said so explicitly. If we are going to try to help you we will need more precision in descriptions, specifically confirmation of assumptions. In such a simple setup, you should not need specifically to create ADJCLUST tables. I think what I would like to see is the sense code generated when the ISTAPNCP entry in the adjacent SSCP list created for the other CICS CDRSC is tried and fails. I think this is going to require a test where you block the possibility of success over the SNI path by disabling that in some way. Just not having the NCP active would be a rather brutal way of doing it or you could simply deactivate the PU statement corresponding to the adjacent link station of the partner configuration in - I assume - your SNI "null" network. One point I left from the previous post is ensuring that the CDRSC for the CICS in the partner system is properly qualified. Perhaps you could post a display of that in order to be sure. It's important that we have confirmation that BN=YES is specified on both sides since, when BN=YES, the XNETALS start option, the default for the XNETALS operand of PU statements representing adjacent link stations, also assumes the YES value.[1] The XNETALS operand refers to some rather complicated options but is vital for setting up sessions where the NetId qualifying the LU name changes. The default value for the XNETALS start option is NO. Another point that is worrying me is that you made a point of mentioning that you were using Interchange Nodes (ICNs). Is this possibly a hint that the CICS systems are supported by VTAM subarea notes other than the ICNs? If so we will need a description of the configuration in terms of which nodes are involved and where the subarea and APPN paths are. Just to be equipped with what I hope is all possibly relevant information, you should post the following from both systems if you still need help: - selected start options SSCPNAME NETID NODETYPE HOSTSA SACONNS BN BNDYN BNORD SNVC ALSREQ CDRDYN CONNTYPE CPCP DYNADJCP DYNLU HPR SORDER SSCPDYN SSCPORD XNETALS - XCA major node for EE - switched major node PU statement for EE - model major node PU statement for EE if used - CDRSC statements for the involved CICS systems - configuration diagram unless just the two border node VTAMs are involved Incidentally, just because I mention a start option, it doesn't mean you should have coded it. It may well be that the default value is quite suitable. You should make sure in the VTAM log that no relevant start options have been rejected. If you need to preserve anonymity, you should substitute useful tokens for names you wish to conceal like the NETA, NETB, CICSA and CICSB you used in your first post. Chris Mason [1] Strangely enough I had remembered that the value of the XNETALS start option was forced to YES when BN=YES is specified but couldn't find any confirmation in the Communications Server (CS) SNA Resource Definition Reference manual - which had me worried for a while since I could see this as a reason for the effects you observed. A thorough search revealed the following in the CS SNA Network Implementation Guide of all places! <quote> When BN=YES is coded, XNETALS=YES is the default start option. When BN=YES is not coded, XNETALS=NO is the default start option. </quote> This is from Appendix I. Border node connection types, Table 70. Connection type for selected VTAM and partner node combinations. In fact, I see that, when during XID exchange, the NetIds are not the same, an APPN node will assume XNETALS=YES for that adjacent link station as long as XNETALS=NO has not been specified. This is - I hope - an accurate version of the poorly expressed note just prior to the note quoted above - and also confirmed something I had a niggling suspicion was the case. This would mean that, as it happens, what is specified for BN in your case is not relevant. On Mon, 14 Dec 2009 02:55:58 -0600, Munif Sadek <[email protected]> wrote: >Duh!!! my EE connection is still not working.. > >Did change BN=YES. dfined new ADJCLUST for the remote network on this >gateway SSCP. > >on displaying ADJCLUST >IST2207I DEFINED TABLE FOR remote_network >IST2209I BNDYN = LIMITED FROM ADJCLUST TABLE >IST2208I BNORD = PRIORITY FROM START OPTION >IST1326I CP NAME TYPE STATE STATUS SNVC >IST1327I remote_network.cpname DYNAMIC ACTIVE NOT SEARCHED >003 > > >anything i can do to change it.. > >regards Munif ---------------------------------------------------------------------- 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
