George
First of all there was a storm of asterisks in your post so that it was
difficult
to work out which were intended as introducing comment lines, which
represented a placement for any number of characters in a model APPL
statement and which were random.
-
Let us say you were faced with the simple situation that, for particular
applications as identified by their APPL names, name AAA in release N changes
to name BBB in release N+1.
What you can do is take the statement
AAA APPL ...
and change it to statement
AAA APPL ACBNAME=BBB
This is because the name the application will specify at the time the VTAM
ACB is "opened" is BBB.
The trouble with the OMEGAMON - I would call it "consolidation" rather
than "coherent" - is that you need to be able to work out what the new
application names are which correspond to the pre-existing names specified in
the session manager.
Doing my own bit of consolidation of your post, I think I have worked out that
the full set of statements proposed somehow by OMEGAMON is as follows:
K&SYSCLONE.M2?P APPL AUTH=
(ACQ,NVPACE,PASS,SPO),PARSESS=YES,SRBEXIT=YES
K&SYSCLONE.M2RC APPL AUTH=(ACQ,NVPACE,PASS),SRBEXIT=NO
K&SYSCLONE.M2EZ APPL AUTH=(ACQ,NVPACE,PASS),SRBEXIT=NO
K&SYSCLONE.M2* APPL AUTH=(ACQ,NVPACE),SRBEXIT=YES
Note EP19ZOOM and other bits and pieces had me puzzled for a while until I
realised you appeared to have missed out part of the "generated" statements.
Accuracy does help enormously and saves a lot of wasted time by anyone
trying to help!
I believe the statements you need are similar to the following:
OM19MVS APPL ACBNAME=K19M2AP,
AUTH=(ACQ,NVPACE,PASS,SPO),
PARSESS=YES,
SRBEXIT=YES
OM19OPR APPL ACBNAME=K19M2¬P,
AUTH=(ACQ,NVPACE,PASS,SPO),
PARSESS=YES,
SRBEXIT=YES
OM19VPO APPL ACBNAME=K19M2¬P,
AUTH=(ACQ,NVPACE,PASS,SPO),
PARSESS=YES,
SRBEXIT=YES
OM19VTAM APPL ACBNAME=K19M2RC,
AUTH=(ACQ,NVPACE,PASS)
EP19ZOOM APPL ACBNAME=K19M2EZ,
AUTH=(ACQ,NVPACE,PASS)
*
K19M2?P APPL ACBNAME=K19M2?P,
AUTH=(ACQ,NVPACE,PASS,SPO),
PARSESS=YES,
SRBEXIT=YES
K19M2* APPL ACBNAME=K19M2*,
AUTH=(ACQ,NVPACE),
SRBEXIT=YES
In the cases of OM19OPR and OM19VPO I've replaced the "?" placeholder
with "¬" just to find a symbol for a letter which you should use specifically
to
identify what new application name corresponds to your previous OM19OPR
and OM19VPO just as, presumably, you discovered that new application
K19M2AP corresponds to your previous OM19MVS. I've also assumed that "19"
is the &SYSCLONE value which it's pointless to specify as &SYSCLONE.
But there is still at least one mystery here so I'm afraid I just haven't been
able to find my way out of the briar patch!
Chris Mason
On Fri, 18 Mar 2011 19:54:10 -0400, George Henke <[email protected]>
wrote:
>*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
