Martin Further to my previous post, I'm very puzzled as to how you could have been setting up those links without appreciating that you were using APPN and that use of APPN links could be responsible for the unexplained transmission group numbers. In addition, since you have been establishing APPN links rather than subarea links and I would have thought that, in the process of setting up such links, you would have appreciated that these were not subarea links.
I'm having to guess wildly - but, according to the principle Sir Arthur Conan- Doyle put into the mouth of Sherlock Holmes,[1] it goes as follows: - You are on z/OS V1R6 or earlier - You want to use XCF links in the Communications Server (CS) IP component (originally known as TCP/IP for MVS) - You are now obliged to specify XCFINIT=YES - You are told in a message during VTAM startup that XCF cannot be initialized - You discover that you need to specify NODETYPE=NN or EN - You do so and VTAM to VTAM XCF links are established between members of the sysplex with TG number 21 The above I can just about understand could happen with an established subarea network which has been running along smoothly for aeons. You would need to be at z/OS V1R6 or earlier since, from V1R7, XCFINIT=DEFINE is the default for a subarea network and this would allow XCF links for the CS IP component without forcing the creation of XCF links for the SNA component (VTAM) - and the subarea network could go slumbering on as if it was still the 1980s! Note that the XCF links are links between VTAM acting as a type 2.1 node as opposed to acting as a type 5 node, that is, APPN links (in the case of links between VTAMs) as opposed to subarea links. What I cannot explain is how/why you have converted your subarea CTC links (VBUILD TYPE=CA) to APPN CTC links (VBUILD TYPE=LOCAL) or have added some APPN CTC links in parallel to your subarea CTC links. Furthermore, if you had set these up in parallel with the XCF links you would have seen them defined with TG number 22. You didn't mention this[2] so I assume you set them up only in order to set up links between sysplexes - which tends to indicate you knew what you were doing - but you didn't ... One rather far-fetched explanation is that someone else who knew (approximately) what he/she was doing was in the process of setting all this up but was "let go" and is incommunicado! Another point in favour of the "let go" theory is that you have not touched VTAM for 20 years but you do not have any NCPs. Someone must have been in charge of converting the network in the last few years in order to deal with the removal of 3745s - surely? Incidentally - perhaps not incidentally for you - when you have digested the implications of using APPN links as well as subarea links and factored this consideration into what you now observe happening to your sessions, you might like to restate your problem concerning "it not being possible to used some logmodes between networks". Talk of "between networks" sounds as if it relates to SNI but you don't have any NCPs so it can't! That's a shame in a way since, indeed, it is possible to have problems trying to use different mode names between networks and the technique for dealing with that problem was a challenge to try to teach - although different COS names was the more difficult challenge! You could have different networks without SNI (and NCPs) but then, before using APPN, you'd be relying on LEN links (links between nodes presenting a basic type 2.1 node appearance to each other). But, again, this would be too complex an environment of which not to be aware - and was introduced into VTAM in 1988 which puts it just at the limit of your 20 years. Furthermore, you should be aware that the subarea PATH does not extend over the LEN link. Still trying to work out what your perceived "logmode" might be, I worry that you may be violating the "Jim Fletcher" rule of APPN networking in VTAM. This rule is to avoid having an APPN route in parallel with a subarea route. This arrangement of routes sometimes works and sometimes does not. The at-the- time VTAM developer Jim Fletcher used to help out a lot in the VM-based fora of the mid-90s and had so many problems trying to sort out and then explain problems customers directly or though their SEs were reporting which had this arrangement of routes as a feature of their configuration, often as a migration step, that he finally just advised never to migrate your configuration in such a way that such an arrangement of routes was created. Chris Mason [1] "...when you have eliminated the impossible, whatever remains, however improbable, must be the truth." But then, making sure I got the words of the quotation above correct, I (re) discovered this other quotation: "I never guess. It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts." [2] "... the curious incident of the dog in the night-time." refers to a similar deduction. On Wed, 3 Sep 2008 10:23:38 -0500, Martin Kline <[EMAIL PROTECTED]> wrote: >I've been all over the manuals, and I don't find this anywhere. It appears that >certain VTAM links, CTCs and others, between LPARs within and without of >the same sysplex, get assigned a default TGN of 21. Why? Shouldn't this be >documented? More importantly, how does this affect PATH definitions, which >contain VRs, and ER/TGN combinations, plus the COS tables that point to VRs, >and the logmodes that point to COS tables? > >Please excuse my ignorance on this. I haven't dealt with VTAM for over 20 >years. Now, I've specified all the (apparently) valid TGNs we had defined (not >including TGN 21), and I find some logmodes that can no longer be used >between networks, while other logmodes still work. The logmodes are available >on all systems, but it appears that there are no routes available for the >logmode-selected COS entries. > >Maybe I'm making this more difficult than necessary. The logmode entries >worked previously, and TGN 21 was never included in the path definitions. Is >there some default that allows any and all TGNs to be used by a given COS? ---------------------------------------------------------------------- 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
