George It might be helpful - for you particularly - if you explain what your reason is for this peculiar procedure.
>From your language, you may be suffering some misunderstandings. In no way does a major node *qualify* a minor node. A major node is merely a separate member of the VTAMLST partitioned data set, library, within which is collected freely a number of minor node definition statements - with some exceptions. The exceptions are NCP and XCA - and they don't concern us here. In the case of APPL statements or LOCAL statements or PU statements in a switched major node, for example, you can split them up in any way that takes your fancy. Once "inside" VTAM, as it were, they may as well all have been contained in one of the corresponding major nodes or in a corresponding major node each or any relationship in between. SNA requires that network accessible units (NAUs)[1] have an unique name. The NAUs are SSCP, PU and LU. The SSCP and PU are found only in subarea SNA and, although the CP is supposedly also unique, it is really just a required LU which uses particular mode names when playing the role of a CP.[2] Thus in "pure" APPN, there are only LUs and any PU *statements* seen in an APPN context are actually used to set up control blocks which represent adjacent link stations with nary an SNA PU entity in sight. In order to perform this peculiar conjuring trick of having one version of an APPL statement active at one time and another version with an identical name active at anther time, you need to remove the first from the VTAM "name space" and that means deactivating the major node. In the days when NCP was king, there was a "trick" which could be played with an SSCP-dependent LU in one NCP having the same name as an SSCP- dependent LU in another simultaneously active NCP. You could "release" and "acquire" the hierarchically superior SSCP-dependent PU using the OWNER and BACKUP NCP operands and the VARY ACQ and VARY REL commands. I *think* some of my students *may* have understood how this worked when I presented the topic! The reason I mention this is that this is the only environment I know where the clash of names is formally allowed and facilities exist to tolerate it - for a reason. Actually I guess I need to acknowledge the session setup implications of the DUPDEFS and DIALRTRY start options. In the case of DUPDEFS, this is all about having LUs with the same name but under different - SNA architectural - nodes, loosely "boxes". In the case of DIALRTRY, this is all about having the same resource accessible under different - SNA architectural - nodes accessed using "switched" facilities. - I've thought of a reason why you might want two "flavours" of an APPL statement definition. You need to keep the same name but - possibly you think - you need to have two different definitions for two different applications performing the same function in a migration scenario. Perhaps the documentation of one application specifies that APPC=YES is needed and the documentation of the other application specifies that APPC=NO is needed. If something like this is what you are facing, it may be that the more demanding application definition is not fatal to the other application. I'm pretty sure you can run an application that may specify APPC=NO with APPC=YES, for example. If the difference is some change to pacing values, are you sure you couldn't achieve the same objective with mode table entry definitions? In other words, what do you really need to do? - [1] In the days of subarea networking this was network addressable units but APPN required a subtle change of name. [2] SNA APPN architecture expresses it differently and in a more complicated manner. This is a consequence of VTAM being unable to allow the SSCP, masquerading as a CP, actually to support "business" sessions. All other APPN implementations, the CP LU can also act as "business" LU - or should be able to! - Chris Mason On Fri, 18 Mar 2011 14:25:32 -0400, George Henke <[email protected]> wrote: >I have the same minor nodes OM22VTAM under 2 different MAJORNODES, A22OMMVS >and A22KOOM1. > >The first MAJORNODE that is varied active activates the minor node and the >other minor node gets a STATUS of RESET. > >If I then want to flip them so that the ACTIVE one becomes RESET and the >RESET one becomes ACTIVE can I do it individually or do I need to VARY the >whole MAJORNODEs INACT and ACT. > >IOW is there a way of qualifying the VARY command with the MAJORNODE name. > > >-- >George Henke >(C) 845 401 5614 ---------------------------------------------------------------------- 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
