Martin If you have XCFINIT=DEFINE, how do you have VTAM XCF links? Although you specify XCFINIT as a VTAM start option, this is purely in order to set up the possibility to have XCF links. The links can be used by either or both of the components of Communications Server (CS), IP (originally TCP/IP for MVS) and SNA (VTAM). If you have XCFINIT=DEFINE and NODETYPE=NN or EN, you are obliged to enter a VARY ACT command for the VTAM invented major node ISTLSXCF in order to convert, as it were, XCFINIT=DEFINE to XCFINIT=YES.
Is it perhaps that your XCF links are only those set up for CS IP? This throws some doubt on whether your other links are SNA rather than IP before we even get to whether or not they are used with subarea SNA or APPN SNA. You should use the D NET,STATIONS command in each of your VTAMs in order to be sure which of your links are subarea links. This command will show the names of PU statements - which are in reality adjacent link stations to adjacent subarea nodes. Where the adjacent link station is ACTIV that will indicate you have a working subarea link. You seem to know about PATH statements, ERs, VRs, subarea COS and mode names so, limiting the links you consider just to those identified as "active" with the D NET,STATIONS command, you should be able to work out what connectivity for sessions you have which relies purely on the subarea part of the network. Now you should use the D NET,CLSTRS command in each of your VTAMs in order to be sure which of your links are APPN links. Again this command will show the names of PU statements - which, in this case, may double as real SNA PU entities but which are always also adjacent link stations to adjacent nodes, either type 2.1 nodes (we will assume always APPN for the moment) or type 2.0 nodes (subarea SNA peripheral nodes). (The type 2.1 nodes can incorporate the functions of a type 2.0 node.) Where the adjacent link station is ACTIV that will indicate you may have an APPN link. From what you know of your configuration you should be able to work out whether the adjacent node is a type 2.0 node or a type 2.1 node. If the adjacent node is a type 2.1 node, the link will be an APPN link. (I am assuming your predecessor has not left you any LEN links.) If the adjacent node is VTAM it will always be an APPN link. An important point of clarity from the last paragraph is that you should be clear - no help from IBM documentation and messages - over what "2", "2.1" and "2.0" mean when talking "SNA". Only an SNA node entity can be "2.1" in spite of IBM stupidity in messages and documentation pretending it applies to the SNA PU entity. At least that stupidity can be ignored since "2.1" must mean node. Only an SNA node entity can be "2.0" in spite of similar IBM stupidity but now it cannot be ignored because, by "2.0", a node entity or a PU entity might be meant in spite of the fact that there is no point in qualifying "2" in reference to a PU entity. I am assuming that, from the names found in the D NET,STATIONS and D NET,CLSTRS commands, you will be able to find out more about the resources defined in the corresponding VTAMLST members. You should now be able to construct a diagram of the nodes which make up the subarea part of the network and a separate diagram for the APPN part of the network. You can verify that the subarea network definitions are working by using the D NET,CDRMS command in each of your VTAMs in order to see whether you have full mesh CDRM connectivity or whether part of the mesh is missing. In each case you will always see the "home" CDRM as ACTIV but you may not see each "away" CDRM as ACTIV. I'm sure you remember all this "stuff". I expect that the VTAM in the new LPAR is the one which will be missing since I guess you have not gone to the extensive trouble of redesigning your PATH statements everywhere. It may be that other VTAMs in recently added LPARs are also missing since your predecessor has relied on APPN to achieve connectivity, possibly relying on the concatenation of a subarea route to an APPN route. He may have got away with this "on a wing and a prayer" in that all the sessions which were expected to be available happened to work. That's probably enough for now. Let me know how you get on with these tasks. Once we have a clear picture of where the subarea routes are and where the APPN routes are, we can try to analyse why you are having session setup failures. When tracking session setup problems you need to check what each VTAM visited by the session setup attempt says. This is done most crudely by setting all start options containing "SIRFMSG" to ALLSSCP (or ALLNNS for LSIRFMSG). These are ASIRFMSG, DSIRFMSG, ESIRFMSG, LSIRFMSG, RSIRFMSG and SIRFMSG itself. You can set these all using MODIFY VTAMOPTS or restart VTAM with the values specified. Your problem is not to do with TGNs because it is almost certainly one of these problems that wouldn't happen if what we used to call the "Jim Fletcher law" was observed. It is very likely to do with giving VTAM a confusing choice for session setup within the various VTAM nodes involved. I can't be sure until the network diagrams are clear. APPN TGs are selected in a manner quite different from subarea TGs and - I think - you have been assuming that the problem relates to subarea PATHs. You will also have to be clear in your own mind what constitutes an SNA network. If you have the same value for the NETID start option in all your VTAMs - and I very much expect you do - you have only one network. Perhaps you really mean sysplex when you say "network" - or this is all rather more complicated than I have been assuming hitherto! Since you are having this experience of differences with different mode names - aka logmodes, also mode table entry names - it may be useful to know whether you use only the mode table entry names which appear in ISTINCLM or you have your own mode table - I suspect the latter. If this is so, do you have multiple mode tables? Do you perhaps see a difference when you use one of the ISTINCLM mode names rather than one of your own mode names? But you mention that the COS specified in your mode table entries is what can distinguish working mode names from those which do not work. However you don't say whether this is subarea COS or APPN COS. I assumed it could not be APPN COS because I have to assume you don't know a lot about APPN - or you'd know where TG number 21 came from! But subarea COS names are not present in ISTINCLM - for the very good reason that there is no standard subarea COS table from which to select names. This indicates you have your own mode tables and your own subarea COS table from which the names are selected. COS selects TG numbers only indirectly. In subarea, the named COS corresponds to a list of VRs (and transmission priorities). If the VR has been activated, the session setup can proceed. If the VR has not yet been activated, the node where the primary LU resides checks that there VR maps to an ER which is active and activates the VR. Then the session setup can proceed. If there is no active ER, the next entry in the list with a different VR number is tried until the list is exhausted. In APPN, the named COS specifies ordered acceptable ranges of characteristics, each with an ascending weight value, for transmission groups and nodes. In the network node responsible for the primary LU, route information for each potential route from the source node to the destination node is gathered. For each potential route, the characteristics of each of the transmission groups and nodes are compared to the acceptable ranges for the specified COS. If none are acceptable, the session setup fails. Where one or more are acceptable, that one or the one where the sum of the weights is lowest is selected and the session setup proceeds. Which type of COS are you talking about? Regarding which nodes are searched: In subarea, you need those CDRM-CDRM sessions I mentioned above. That is what determines which nodes are searched. In APPN, all nodes which are connected together, and where there is a concatenation of CP-CP sessions between them, are searched. The "concatenation" point is important but you can usually just assume it when you simply have the connections since, in your configuration by default, APPN mechanisms will ensure the necessary CP-CP sessions are established. However, this does prompt me to ask what your design for the assignment of network nodes and end nodes is. This is going to depend on your network configuration and you should note down for each VTAM whether it is an end node (NODETYPE=EN) or a network node (NODETYPE=NN). This may matter when checking for problems setting up sessions. You should also note that specification your predecessor decided on for the SORDER start option in each VTAM and the SSEARCH start option in each network node VTAM. These start options affect how a search switches between subarea mechanisms and APPN mechanisms. It occurs to me that those OSA features might include SNA links to non-VTAM APPN nodes. Do they, and, if so, do we need to take this wider part of the SNA network into account when sorting out the session setup problems? Also if the CIP links are relevant, you'd better explain where they fit in. That probably really is enough for now. I await the next instalment. Incidentally, if you want to persuade your management concerning SNA education, you can simply point out that, without it, they can add as many LPARs as they like to the configuration as long as they don't expect to run any SNA applications there which work with the rest of the SNA network. It would be possible to run TSO, a probably rather important "for example", as long as the adjacent CS IP is fitted with a TN3270 server but no more. If they can live with that there's no need to pay for SNA education. I guess you could always pay for a consultant from IBM whenever you needed SNA-related projects run but I'm not sure your management would like to pay out the "big green" for "Big Blue". Chris Mason On Thu, 4 Sep 2008 13:39:54 -0500, Martin Kline <[EMAIL PROTECTED]> wrote: >Hi Chris, > >>>snip >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. >>>unsnip > >Actually, I wasn't setting up the links. They already exist. I managed to >partially break them, and want to ensure I understand the underlying problem >before moving forward. > >>>snip >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! >>>unsnip > >We're at z/OS 1.7. We use the default XCFINIT=DEFINE, but we have a mixed >conglomeration of CTC, XCF, OSA and CIP links. We have two separate >sysplexes. Both sysplexes have four LPARs. All of the LPARs are on a total of >five machines. > >For background, the network team disolved after the primary SNA support >person left the company, and his "backup", for lack of a better name, refused >to deal with SNA. > >Nothing had changed for some time until we added the fourth LPAR to one of >the sysplexes, and I started monkeying around. > >>>snip >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! >>>unsnip > >Bingo! > >>>snip >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? >>>unsnip > >To the best of my knowledge, we have not had an NCP here for at least eight >years. How the conversion happened is unknown. > >As far as I can tell, we use CTCs between the two networks. > >>>snip >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. >>>unsnip > >The reason I believe my issue has something to do with TGNs is this. Using a >single LU on one system, I can connect to various applications on the second >network using one logmode but not another. I can even connect to >applications on one LPAR on the other network but not on another LPAR using >the same logmode. All of the logmode entries are in the default logmode table >on all of the LPARs on the second network. > >The connection error I get is 087D0001, indicating the destination application >is not found. So the application can be found with some logmodes, but not >with others. I do NOT get any error indicating the logmode is unknown. The >logmodes that work use a different COS than the ones that don't work. The >COS specifies the TGNs that can be used. My understanding is that this will >affect which nodes are searched for the target application. > >One more thing. You mentioned training. Ha Ha. Training here is something >management gives a lot of lip service, but which is rarely funded. My need for >a better understanding of VTAM and IP is considered extremely UNimportant. >Maybe the simplest thing I could do to get training is to cause serious network >disruptions. Would management get the message then? Probably not. ---------------------------------------------------------------------- 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
