George
I should have added that the name of the APPL statement, A, and the name
which is the value of the ACBNAME operand, B, are *not* equivalent.
A can be matched both by session requests from other SNA domains, say
VTAMs, whereas B can be matched by session requests only in the same
VTAM SNA domain. Thus if the session manager application uses the API of
the same VTAM used by the API of OMEGAMON, using the value of the
ACBNAME operand works, otherwise not.
Here's a representation of my lecture material on the topic:
<acbname>
The Uninterpreted Name
----------------------
SNA defines two names for LUs
1. the network name - known throughout the network
2. the uninterpreted name - known only in the domain
VTAM implements this for
- application LUs only
Network name Uninterpreted name
| |
----+---------------------+------------------
| V V |
| A51TSO APPL ACBNAME=TSO, * |
| ... |
---------------------------------------------
Notes:
The session initiation requests INIT-SELF and INIT-OTHER carry the names of
the LUs as uninterpreted names. The reason for the description uninterpreted
is that the SSCP will attempt to match the name first to the
uninterpreted name for a destination LU in its own domain before considering
the name as an interpreted name. It will then try to match the interpreted
name to the name for the destination LU before initiating a cross-domain
request with the interpreted name.
Note: This function must not be confused with
- the SNI alias function
- the VTAM INTERPRET table
- USERVAR
VTAM makes use of this possibility to provide for an application LU to have
- a name known locally to the VTAM in the same host, same domain
- a name known throughout the network which can be used for cross-domain,
and cross-network, session initiation requests
Thus an application can have the same name in all hosts in a network,
simplifying product installation where a product can be "customized" in one
host and propagated to all hosts in the network.
The uninterpreted name is the name given by the ACBNAME operand of the
APPL statement. It is the name specified within the application program's
application control block, ACB.
The interpreted name is the name given as the name of the APPL statement
and becomes also the uninterpreted name if there is no ACBNAME operand.
Since the name must be used for cross-domain session initiation, it is also
called "the network name".
There are times when the interpreted name must be used if the application is
sensitive to a name change. For example, the terminal access facility, TAF,
component of NetView Secondary Logical Unit, SLU, checks that the name
used to initiate a TSO session has the same leading characters as the name
which appears in the eventual BIND request unit. TSO uses the interpreted
name when initiating the second session and so the name used to initiate the
first session must be the interpreted name. A device-type SLU is not so
particular!
</acbname>
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
