*This was the original VTAM APPL definition for generated by OMEGAMON ICAT
for the new config:*
**
* CUA LOGON APPLID
*K&SYSCLONE.M2?P APPL* AUTH=(ACQ,NVPACE,PASS,SPO), X
PARSESS=YES,SRBEXIT=YES
*
* CLASSIC LOGON APPLID
*K&SYSCLONE.M2RC APPL* AUTH=(ACQ,NVPACE,PASS),SRBEXIT=NO
*
*
But we wanted our end-users to use their current APPLIDs so they did not
need to redefine their CLSS SuperSession profiles to log in:
*
**
*CURRENT APPLS:*
*A19OMMVS VBUILD TYPE=APPL *
***********************************************************************
*** ***
*** THIS IS AN EXAMPLE OF OM/2 APPL DEFINITIONS ***
*** ***
***********************************************************************
*OM19MVS APPL* AUTH=(ACQ,NVPACE,PASS), X
PARSESS=YES,SRBEXIT=YES
OM19OPR APPL AUTH=(ACQ,NVPACE,PASS), X
PARSESS=YES,SRBEXIT=YES
OM19VPO APPL AUTH=(ACQ,NVPACE,PASS,SPO), X
PARSESS=YES,SRBEXIT=YES
*OM19VTAM APPL* AUTH=(ACQ,NVPACE,PASS),SRBEXIT=NO
EP19ZOOM APPL AUTH=(ACQ,NVPACE,PASS),SRBEXIT=NO
************************************************************************
*Since the ACBNAME was not coded in any of these APPLs, the ACBNAME and the
APPL were the same.*
**
*So I made the APPL name for the new config the same as the old APPL names,
but related it to the new ACBNAME as follows thereby making the new APPLs
synonymous with the old APPLs. Do you see any problem with this?*
*NEW APPLS:*
*A19KOOM1 VBUILD TYPE=APPL *
* CUA LOGON APPLID
K&SYSCLONE.M2?P APPL AUTH=(ACQ,NVPACE,PASS,SPO), X
PARSESS=YES,SRBEXIT=YES
*
*OM19MVS APPL* AUTH=(ACQ,NVPACE,PASS,SPO), X
PARSESS=YES,SRBEXIT=YES,*ACBNAME=K&SYSCLONE.M2AP*
*
* CLASSIC LOGON APPLID
*OM19VTAM APPL* AUTH=(ACQ,NVPACE,PASS),SRBEXIT=NO, X
*ACBNAME=K&SYSCLONE.M2RC*
*
* ZOOM-TO-EPILOG HISTORICAL APPLID
K&SYSCLONE.M2EZ APPL AUTH=(ACQ,NVPACE,PASS),SRBEXIT=NO
*
* VIRTUAL TERMINAL POOL
K&SYSCLONE.M2* APPL AUTH=(ACQ,NVPACE),SRBEXIT=YES
*
tyvm
On Fri, Mar 18, 2011 at 6:51 PM, Chris Mason <[email protected]>wrote:
> George
>
> I think the key point you need is that, when you deactivate the major node,
> you remove the major nodes from VTAM - use D NET,MAJNODES to observe
> this - and you remove the contained APPL statement minor nodes from the
> VTAM "name space" and that VTAM will have forgotten that they ever existed.
> Other VTAMs will still have representations of that minor node as CDRSCs
> but,
> if the original VTAM reintroduces the APPL statement minor node names
> again,
> it doesn't matter since the CDRSC, in a subarea context and mainly in an
> APPN
> context, just names, the name itself and names of potentially owning CDRMs
> or CPs, in effect, VTAMs.
>
> So, you activate the major node(s) which go along with the old application
> setup at one time. Run the old application. Shut down the old application.
> Deactivate the major node(s). Activate the major node(s) which go along
> with
> the new application setup. Run the new application. And so on.
>
> Of course, you can check on the status of the APPL statements with D
> NET,ID=major-node-name,E.
>
> Does that cover what you need?
>
> If you post representative versions of the APPL statements in their major
> nodes, I might be able to spot a simplification.
>
> Chris Mason
>
> On Fri, 18 Mar 2011 16:45:25 -0400, George Henke <[email protected]>
> wrote:
>
> >tyvm, Chris, you really know this stuff.
> >
> >This is for a migration to a new OMEGAMON CICS.
> >
> >We have completely reconfigured OMEGAMON CICS with a new version that
> has
> >all different MAJOR and minor node names which are more coherent.
> >
> >However, we needed to retain the APPL name so end users can still log into
> >OMEGAMON CICS without changing their VTAM APPLIDs in their CLSS
> SuperSession
> >profiles.
> >
> >So we duplicated several APPL minor node names, not acbnames, in the new
> >OMEGAMON Major node and now that we need to migrate from the old
> OMEGAMON to
> >the new we are trying to figure out the VTAM commands needed so that
> there
> >is no conflict or confusion between the two duplicate names when we vary
> >them inact and act.
> >
> >We just tried a test this afternoon and everything worked fine.
> >
> >But the new major node was not already active and so the minor was not in
> a
> >RESET status.
> >
> >So we don't know what would have happened in a fallback scenario where the
> >duplicate minor is in a RESET state.
> >
> >I am wondering if a simple vary act will activate it after the active
> minor
> >has been inact'd.
> >
> >This is probably as clear as mud, but it is what we are trying to do.
> >
> >On Fri, Mar 18, 2011 at 4:26 PM, Chris Mason
> <[email protected]>wrote:
> >
> >> 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
>
--
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
