LOGMODE And COS Resolution 
In Mixed APPN/Subarea Networks

Johnathan Harter
CS For OS/390 Development
yoda@us.ibm.com

This paper is intended to be used with and further explain the corresponding Freelance presentation by the same name.  The presentation and this paper were created by Johnathan L. Harter, Senior Software Engineer at IBM Corporation (yoda@us.ibm.com), who has worked on the VTAM (SNA) side of Communications Server For OS/390 since the earliest inception of APPN in VTAM (Version 4 Release 1).  A list of acronyms used is included at the end of the paper.

Chart 1 - Title Page

For most customers, migrating from subarea networking to APPN means migrating  from 37xx nodes with NCP to stand-alone APPN NNs or ENs with DLUR/DLUS (like the 2216 or the 3746).  One common challenge encountered during the migration from subarea to APPN is Logon Mode (LOGMODE) and Class of Service (COS) resolution.  This presentation gives a detailed description of how LOGMODE names and COS names are resolved by VTAM in subarea networks, APPN networks and mixed APPN/subarea networks.

The biggest obstacle faced by most customers when addressing issues related to LOGMODE name and COS name resolution in mixed APPN and subarea networks is understanding.  Many customers have asked why LOGMODE name and COS name handling in APPN networks is so much different than subarea networks.  The answer lies in the history of the evolution of the APPN architecture, which was developed by a group within IBM that wanted the ability to start sessions between two instances of their product without involving VTAM (the mainframe SNA networking product).  Because of this, APPN was developed without any influence from the VTAM organization and without detailed knowledge of the subarea architecture.  APPN was intended to be used for LU 6.2 protocols only, so the APPN architecture addressed only the needs of this protocol.

When VTAM implemented APPN several years later, it included functions to accomodate for the differences in the way APPN and subarea protocols operate.  VTAM worked with the APPN architects to extend the architecture to support dependent LUs, non-LU 6.2 protocols (like LU0 and LU2) and the richness of function customers have come to expect from VTAM's Application Programming Interface.  At the same time, the VTAM organization realized that customers would not be able to migrate from subarea to APPN all at once.  Instead, customers would likely have both APPN and subarea within their network for some time.  

In order to leverage existing VTAM customers' investments, the VTAM implementation must provide customers with as smooth a migration path to APPN as possible.  This means that sessions must be allowed to traverse both APPN and subarea portions of the network, with an Interchange Node (ICN) performing the necessary subarea-to-APPN protocol conversion.  It is this protocol conversion between the two disparate networking architectures that results in many of the complexities of migrating from subarea to APPN.  Since VTAM is the only product capable of performing this protocol conversion, these complexities are typically unique to VTAM.

Chart 2 - Overview Of LOGMODE & COS Resolution

Before describing how LOGMODE name and COS name resolution works in a mixed subarea/APPN network, it is important to first understand how LOGMODE name and COS name resolution works in "pure" subarea and "pure" APPN networks.  

Subarea Networks

In subarea networks, the LOGMODE name that should be used for a session is typically chosen by the OLU.  If the OLU is also the SLU and a LOGMODE name is not specified, the SSCP that owns the OLU chooses an appropriate default LOGMODE name.  However, if the OLU is the PLU and a LOGMODE name is not specified (a BLANK LOGMODE name is provided), this indicates that the PLU is deferring selection of the (default) LOGMODE name to the SSCP that owns the SLU.

NOTE 1:  The default LOGMODE name for a session is determined by the DLOGMOD= operand on the SLU definition.  If there is no DLOGMOD associated with the SLU, then the first LOGMODE entry in the SLU's MODETAB is used as the default LOGMODE name.  If no LOGMODE table is associated with the SLU, then the first LOGMODE entry in IBM's default LOGMODE table (ISTINCLM) is used as the default LOGMODE name.

The LOGMODE name is then used to determine the subarea COS name for the session.  (A different subarea COS name can be specified on each LOGMODE entry in each LOGMODE table using the COS= operand.)  The subarea COS name is always chosen at the SSCP that owns the SLU, regardless of whether the SLU is the OLU or DLU of the session.  If the session traverses a subarea network (SNI) boundary, the subarea COS name can be translated at each SNI boundary to an equivalent subarea COS name for the adjacent subarea network.  This occurs when the session setup request or response is sent from the SSCP that owns the SLU toward the SSCP that owns the PLU.

Once the subarea COS name is received by the SSCP that owns the PLU (or the GWSSCP closest to the PLU in each SNI network), this SSCP chooses the VR list that should be used for the session by looking up the subarea COS name in the Subarea COS Definition table (ISTSDCOS).  The first available VR in the list is then activated and used for the session.

APPN Networks

As with subarea networks, the LOGMODE name for an APPN session is typically chosen by the OLU.  Because all APPN sessions were LU 6.2 sessions (at least at first), the OLU was always the PLU of the session.  No special provisions were made for BLANK LOGMODE names, because the OLU (PLU) always provided a real LOGMODE name when initiating a session.

The LOGMODE name is then used to determine the APPN Class Of Service (COS) name for the session.  The APPN COS name is always chosen by the CP that owns the OLU or by the NNS of the OLU (if the OLU resides on an EN and the EN did not choose an APPN COS name).  This means that, by the time an APPN search leaves the NNS(OLU), the APPN COS has already been chosen (without first determining anything about the LOGMODE or COS specifications at the session partner's node).  If the session traverses an APPN network boundary, the APPN COS name can be mapped at each APPN network boundary to an equivalent APPN COS for the adjacent APPN network using a BN COS Mapping (BNCOSMAP) table.  APPN BN COS Mapping always occurs during the Request Phase of the search.

When the APPN Locate Reply is returned to the NNS(OLU), this NN now has everything it needs to compute the path that will be used for the session.  The APPN COS name and definition, the network Topology Database and any endpoint TGVs sent by the OLU and/or DLU are used to compute the least weight route for the session.  This least weight route is described in an RSCV which is returned to the CP(OLU) for inclusion on the ensuing BIND.

NOTE 2:  In mixed subarea and APPN network configurations, it is sometimes necessary to compute the session RSCV before sending the APPN Locate Request.  This special case is not considered in detail during this presentation, because it has no affect on LOGMODE name and COS name resolution.

Summary

When reviewing subsequent charts in the presentation, it will be useful to remember the following items regarding LOGMODE name and COS name resolution:

a.	COS names and default LOGMODE names are always chosen by VTAM using the MODETAB and DLOGMOD values associated with the SLU.  This is true regardless of whether the SLU is the OLU or DLU of the session.
b.	The subarea COS name is always chosen at the SLU-side of each subarea network; the APPN COS name is always chosen at the OLU side of each APPN network.

Chart 3 - Subarea Network Examples

Looking at some examples will help to solidify understanding of the rules presented on the previous chart.  This chart shows three subarea examples, all of which use the same configuration.  The PLU resides on a VTAM DH; the SLU is attached to an NCP that is owned by the VTAM CMC (which owns the network).

Subarea Example #1

In the first example, the PLU initiates the session and provides a specific LOGMODE name (MODE) to be used for the session.  The LOGMODE name is sent from the SSCP(PLU) to the SSCP(SLU) on a CDINIT request.  The SSCP(SLU) looks up the received LOGMODE name in the SLU's MODETAB or the IBM default LOGMODE table, ISTINCLM, and retrieves the value specified by the COS= operand.  This subarea COS name (SCOS) is then returned to the SSCP(PLU) on the CDINIT response.

Subarea Example #2

The second example is the same as the first, except that the PLU does not provided a LOGMODE name (a BLANK LOGMODE is provided instead).  In this case, the BLANK LOGMODE name is sent from the SSCP(PLU) to the SSCP(SLU) on the CDINIT request.  Because the LOGMODE is BLANK, the SSCP(SLU) chooses a default LOGMODE for the session by using either the SLU's DLOGMOD value (if specified) or the first LOGMODE entry in the SLU's MODETAB or the IBM default LOGMODE table, ISTINCLM.  VTAM then looks up the default LOGMODE name in the SLU's MODETAB (or ISTINCLM) and retrieves the value specified by the COS= operand.  The resolved default LOGMODE name (MODE) and subarea COS name (SCOS) are then returned to the SSCP(PLU) on the CDINIT response.

Subarea Example #3

The third example shows a session that is initiated by the SLU.  If the SLU does not provide a specific LOGMODE name on the session initiation request, then the SSCP(SLU) chooses a default LOGMODE name for the session by using either the SLU's DLOGMOD value (if specified) or the first LOGMODE entry in the SLU's MODETAB or ISTINCLM.  Once the LOGMODE name has been resolved, VTAM then looks up the LOGMODE name in the SLU's MODETAB (or ISTINCLM) and retrieves the value specified by the COS= operand.  Both the LOGMODE name (MODE) and the subarea COS name (SCOS) are sent to the SSCP(PLU) on the CDINIT request.

Chart 4 - APPN Network Examples

This chart shows three APPN examples, all of which use the same configuration.  The PLU resides on a VTAM EN; the SLU is attached to an NCP that is part of a VTAM CNN (which also doubles as the CMC).

NOTE 1:  Because the CP(SLU) also happens to be the NNS(PLU), the APPN RSCV looks like it is computed at the SLU-side of the APPN network.  However, if the PLU and SLU were served by different NNSs, the RSCV would be still be computed by the NNS(PLU).

APPN Example #1

In the first example, the PLU initiates the session and provides a specific LOGMODE name (MODE) to be used for the session.  Because APPN searching is being performed, the APPN COS name must be determined before sending the APPN Locate request.  The CP(OLU) looks up the specified LOGMODE name in the SLU's MODETAB or the IBM default LOGMODE table, ISTINCLM, and retrieves the value specified by the APPNCOS= operand.  The LOGMODE name (MODE) and APPN COS name (ACOS) are then included on the APPN Locate request that is sent toward the CP(DLU).  When the APPN Locate reply is returned to the CP(OLU), the RSCV for the session is included on the reply by the NNS(PLU) (if the PLU resides on an EN) or is computed by the CP(PLU) (if the PLU resides on an NN) for inclusion on the ensuing BIND.

APPN Example #2

The second example is the same as the first, except that the PLU does not provide a LOGMODE name (a BLANK LOGMODE is provided instead).  As with the previous example, the APPN COS name must be determined before sending the APPN Locate request.  However, in this case, the APPN COS name must be chosen based on a BLANK LOGMODE name.  So, this VTAM must first choose a default LOGMODE name using the SLU's DLOGMOD value (if specified) or the first LOGMODE entry in the SLU's MODETAB or ISTINCLM.  Once the default LOGMODE name is determined, VTAM looks up this LOGMODE name in the SLU's MODETAB or ISTINCLM and retrieves the value specified by the APPNCOS= operand.

Now that the APPN COS name (ACOS) has been resolved, it is included on the APPN Locate request that is sent toward the DLU.  Notice, however, that the LOGMODE name included on this APPN Locate request is the original BLANK LOGMODE name, not the "default LOGMODE name" (as resolved by this node).  This is done to preserve the way BLANK LOGMODEs are handled in subarea networks...that is, to allow the SSCP that owns the SLU to choose the default LOGMODE name for the session.

When the APPN Locate request is received by the VTAM that owns the SLU (the CNN), the BLANK LOGMODE name is resolved to a default LOGMODE name in the usual manner (see above).  But because this is the SSCP that owns the SLU, the default LOGMODE name replaces the BLANK LOGMODE name received on the APPN Locate request.  (This allows the CNN to use the default LOGMODE name to choose which subarea COS to use "through the CNN", as will be discussed later.)  The APPN Locate reply returned to the CP(OLU) includes the resolved default LOGMODE name (MODE).  In addition, the RSCV for the session is included on the reply by the NNS(PLU) (if the PLU resides on an EN) or is computed by the CP(PLU) (if the PLU resides on an NN) for inclusion on the ensuing BIND.

NOTE 2:  Although the BLANK LOGMODE name is replaced by the default LOGMODE at the SSCP(SLU), the received APPN COS is not changed!  The APPN COS name received on the APPN Locate request is always retained and used for the session.

APPN Example #3

The third example shows a session that is initiated by the SLU.  If the SLU does not provide a specific LOGMODE name on the session initiation request, then the SSCP(SLU) chooses a default LOGMODE name for the session by using either the SLU's DLOGMOD value (if specified) or the first LOGMODE entry in the SLU's MODETAB or ISTINCLM.  Once the LOGMODE name has been resolved, VTAM then looks up the LOGMODE name in the SLU's MODETAB (or ISTINCLM) and retrieves the value specified by the APPNCOS= operand.  Both the LOGMODE name (MODE) and the APPN COS name (ACOS) are sent toward the CP(PLU) on the APPN Locate request.  In addition, if "session queuing" is not required, then this VTAM (as the NNS(PLU)) computes the RSCV for the session and includes it on the APPN Locate request as well.

Due to the way SLU-initiated sessions were implemented in the APPN architecture (to save flows through the network), it is quite likely that the BIND request and response will flow next.  In this case, the reply to the APPN Locate request is returned after the BIND response is returned (and the session is effectively ACTIVE).

Chart 5 - What About Mixed Networks?

With a clear understanding of how LOGMODE names and COS names are resolved in subarea networks and in APPN networks, it is now time to discuss how LOGMODE names and COS names are resolved in mixed subarea and APPN networks.  The first step is simply to recognize where the APPN and subarea networks are.  In the figure provided, it seems very clear which parts of this network are APPN versus subarea.  However, what is not generally known is that even "pure" VTAM NNs and ENs have some amount of "subarea" to them.  For example, they all have a subarea number (even if they are all using the default subarea number, 1).  They also continue to assign network addresses and use them for subarea (FID4) routing, even though the VRs/ERs being used are completely contained within the same subarea.

With this in mind, it is now much easier to identify where the subarea and APPN parts of this network are.  There are two (2) APPN parts to this network:  one between the EN(PLU) and the ICN on the left, and one between the ICN on the right and the NN(SLU).  And there are three (3) subarea parts to this network:  one is the EN(PLU) itself, one is the NN(SLU) itself, and the last is the obvious one between the two ICNs.  This is important is because VTAM must follow the rules for each type of network when resolving LOGMODE names and subarea and APPN COS names.  So knowing where the APPN and subarea networks are is key.

Chart 6 - Mixed APPN and Subarea Networks

As mentioned on the previous chart, when resolving LOGMODE names and COS names, VTAM must follow the rules defined for each type of network regarding which node is responsible for resolving which values.  And if multiple APPN and/or subarea networks exist on a session path, these rules must be followed within each of these networks.

The examples that follow should help to clarify this.  However, before moving on to these examples, it is important to understand the two methods that VTAM can use to resolve subarea and/or APPN COS names.  The first method is called the LOGMODE table method.  With the LOGMODE table method, the VTAM responsible for resolving the subarea and/or APPN COS name(s) looks up the LOGMODE name (which could be the default LOGMODE name) in the SLU's MODETAB (or ISTINCLM) and retrieves the value(s) specified on the COS= and/or APPNCOS= operands (depending on which are needed).

The second method is called the COS Mapping table method.  With the COS Mapping table method, VTAM maps (for example) the received subarea COS to an equivalent APPN COS (or vice versa), thereby avoiding another LOGMODE table lookup.  The COS Mapping table method is only used when COS Mapping tables are explicitly defined to VTAM.  Two types of COS Mapping tables can be created to define the COS mapping in each direction:  the APPN-to-Subarea (VBUILD TYPE=APPNTOSA) and the Subarea-to-APPN (VBUILD TYPE=SATOAPPN) COS mapping tables.  

Once APPNTOSA and/or SATOAPPN COS Mapping tables are defined, VTAM uses the COS Mapping table method in preference to the LOGMODE table method when resolving subarea and/or APPN COS names.  However, if a COS mapping has not been defined (or the COS Mapping table does not include an appropriate mapping), VTAM will revert back to the LOGMODE table method.  In fact, even if both APPNTOSA and SATOAPPN COS Mapping tables have been defined, VTAM must still use the LOGMODE table method at least once during each session establishment.  The reason for this is because the COS Mapping table method requires that one COS name (either APPN or subarea) already be known in order to map it to the other (subarea or APPN) COS name.  VTAM always uses the LOGMODE table method to resolve the very first COS name, and it is always the subarea COS name that is resolved first by this method.  That is, if the APPN COS name is needed, then VTAM first uses the LOGMODE table method to resolve the subarea COS name, and then uses the SATOAPPN COS Mapping table to resolve the APPN COS name.

NOTE:  Just because VTAM prefers the COS Mapping table method (the "new" way) over the LOGMODE table method (the "old" way) does NOT mean that VTAM Development recommends using the COS Mapping table method over the LOGMODE table method.  As subsequent charts demonstrate, the COS Mapping table method does not work intuitively in all cases.  Furthermore, it was originally felt that the main advantage of using the COS Mapping table method was to avoid having to do a lot of LOGMODE table rework before enabling APPN.  Since at least some LOGMODE table work must be performed anyway (in order to ensure that the very first subarea COS name is resolved correctly, see above), it is generally felt that, once this work is completed, the additional work needed to use the LOGMODE table method all of the time is trivial.

One final note:  regardless of which method is used, subarea and APPN COS names are still resolved by following the rules for each type of network:  the APPN COS name is chosen at the OLU-side of each APPN network; the subarea COS name is chosen at the SLU-side of each subarea network.

Chart 7 - COS Resolution:  LOGMODE Table Method

This chart shows an excerpt from the IBM-supplied default LOGMODE table, ISTINCLM, except that the COS= operand has been added.  (As shipped, the ISTINCLM table does not include the COS= operand on most of the entries, because there are no "standard" subarea COS names.  Starting with VTAM V4R1, ISTINCLM does include one of the standard APPN COS names on each LOGMODE entry.)  Rather than modify ISTINCLM, most customers create their own LOGMODE tables and add new LOGMODE entries to these tables instead.  This excerpt is only provided as an example.

The LOGMODE Table method of resolving subarea and/or APPN COS names is very straight forward.  The VTAM that is responsible for resolving the subarea and/or APPN COS name(s) simply looks up the session's LOGMODE name in the SLU's MODETAB (or ISTINCLM) and retrieves the value(s) specified by the COS= and/or APPNCOS= operands.  The 
LOGMODE table method is used:

a.	when the necessary COS Mapping table (APPNTOSA or SATOAPPN) does not exist (is not defined),
b.	when the necessary COS Mapping table (APPNTOSA or SATOAPPN) does exist, but there is no direct (or default) mapping for the COS name that is being mapped, or
c.	to resolve the very first (subarea) COS name, when neither the APPN nor the subarea COS name is known yet.
There is also one special LOGMODE entry that can be coded in a LOGMODE table.  It is the LOGMODE entry called ISTCOSDF.  Depending on the value of the corresponding start option (ISTCOSDF, see below), this LOGMODE entry may be used by VTAM as the "default LOGMODE entry" when the received LOGMODE name cannot be found in the SLU's MODETAB (or ISTINCLM).  The IBM default LOGMODE table (ISTINCLM) already contains a LOGMODE definition for ISTCOSDF .  However, there is no reason why an ISTCOSDF entry could not be defined in one or more user-defined LOGMODE tables as well.

The ISTCOSDF start option controls what types of resources (SLUs) are allowed to use the default LOGMODE entry during establishment of a session.  It can be coded with any combination of "Application" (APPL), "Dependent LU" (DEPLU) and/or "Independent LU" (INDLU) resource types (or ALL or NONE).  The default value for the ISTCOSDF start option allows the default LOGMODE entry to be used only for independent LUs.

NOTE:  When deciding whether the ISTCOSDF LOGMODE entry can be used for a particular session, the VTAM that performs the LOGMODE table lookup uses it's own representation of the SLU to make this determination.  For example, an application (or dependent LU) that resides on VTAM1 is represented by a CDRSC on VTAM2.  If this resource is the SLU and VTAM2 must decide whether the ISTCOSDF LOGMODE entry can be used, it checks to see if the ISTCOSDF start option value includes INDLU (Independent LUs/CDRSCs), since that is how the SLU is represented in VTAM2.  VTAM2 has no way of knowing whether this CDRSC actually represents an application or a dependent LU in the owning VTAM (VTAM1).

Chart 8 - COS Resolution:  COS Mapping Table Method

COS Mapping tables are defined using VBUILD macros with TYPE=APPNTOSA or TYPE=SATOAPPN specified.  The COS Mapping tables are used by VTAM to resolve a subarea or APPN COS name when the other COS name (APPN or subarea respectively) is already known.  For example, if an APPN COS name must be chosen by a given VTAM and the subarea COS name is already known, then the SATOAPPN COS Mapping table is used to map the known subarea COS name to an appropriate APPN COS name.  (If the subarea COS name is not yet known, VTAM uses the LOGMODE table method to choose a subarea COS name; then maps this subarea COS name to an appropriate APPN COS name.)  

If the appropriate COS Mapping table (APPNTOSA or SATOAPPN) is defined and a direct or default mapping exists for the "input COS name" that is being mapped, then the COS Mapping table method is used by VTAM in preference to the LOGMODE table method.  If the appropriate COS Mapping table is not defined or a direct or default mapping does not exist for the "input COS name", then VTAM reverts back to the LOGMODE table method.  DEFAULT=YES is used to specify the default mapping that should be used for all "input COS names" that do not have an explicit mapping defined.

Notice that the APPNTOSA COS Mapping table shown on this chart includes a mapping for the #CONNECT APPN COS name, but does not include a value for the COS= operand.   This is the means by which customers can map one or more APPN COS names to the default (BLANK) subarea COS name.  Similarly, when defining the SATOAPPN COS Mapping table, the BLANK subarea COS name can be mapped to an appropriate APPN COS name by omitting the "label" field before the MAPSTO keyword.  (The ability to map to or from the BLANK subarea COS name was added by APAR OW28568.)  This function is not supported for APPN COS names, because a BLANK APPN COS name is not supported by the APPN architecture.

NOTE:  Because different tables are used to map subarea versus APPN COS names, it is possible to map COS  names differently in each direction.  There is no clear benefit in doing this, however, and in some cases (like when the PLU initiates a session without providing a LOGMODE name) defining COS Mapping tables that are not inverse mappings can cause what seems to be unpredictable results.  For  usability, it is recommended that the APPNTOSA and SATOAPPN COS Mapping tables be defined as close to inverse mappings as possible.

Chart 9 - APPN-Subarea-APPN SLU-Initiated Session

The next two charts walk through more complicated examples of the LOGMODE name and COS name resolution logic that takes place at various VTAM nodes during session establishment in a mixed subarea/APPN network.  The network configuration used for both examples is described as APPN-Subarea-APPN.  However, given the fact that even "pure" VTAM NNs and ENs perform at least some subarea function internally, these examples could actually be thought of as Subarea-APPN-Subarea-APPN-Subarea configurations.

The first example (on this chart) shows a session that is initiated by the SLU.  Note that, when the terms MODE, SCOS and ACOS are shown above an arrow (within a Locate or CDINIT signal), this means the LOGMODE name and/or COS name is included on that signal.  When these terms are shown on one of the ends of an arrow (below a specific node and not within a Locate or CDINIT signal), this means that the node depicted above the term is responsible for resolving the LOGMODE name and/or COS name(s).

NN That Owns The SLU (Request Phase)

When the SLU initiates a session, the VTAM that owns the SLU (the NN on the far right) must ensure that a LOGMODE name has been chosen for the session.  If the SLU provided a LOGMODE name on the session request, that LOGMODE name will be used for the session.  Otherwise, this VTAM (as the SSCP(SLU)) will choose a default LOGMODE name based on the SLU's DLOGMOD value (if specified) or the first LOGMODE entry in the SLU's MODETAB (or ISTINCLM).  

Once the LOGMODE name for the session has been determined, the subarea COS name (for use internally within this NN) must be determined, since this is the VTAM that owns the SLU.  VTAM looks up the LOGMODE name in the SLU's MODETAB (or ISTINCLM) and retrieves the value specified on the COS= operand.

When both the LOGMODE name (MODE) and subarea COS name (SCOS) have been determined, this VTAM begins searching for the partner resource.  However, before this search can be sent into the APPN network (in the form of an APPN Locate request), the APPN COS name must already be determined (since this VTAM is the APPN node closest to the OLU).  If an SATOAPPN COS Mapping table is defined, then VTAM uses it to map the subarea COS name (SCOS) to an appropriate APPN COS name.  If an SATOAPPN COS Mapping table does not exist or does not contain a mapping for the subarea COS name, then the LOGMODE table method is used to resolve the LOGMODE name to an APPN COS name.

NOTE 1:  In general, both the subarea COS name and the APPN COS name are retrieved during the same scan of the LOGMODE table, in case they are both needed.  That is, the LOGMODE table is typically not searched twice (once to get the subarea COS name and then again to get the APPN COS name).

SLU-Side ICN (Request Phase)

After the APPN COS name (ACOS) has been determined, an APPN Locate search request is sent into the APPN network to find the partner resource.  When this search request is received by the ICN in that APPN network (the ICN on the right), the search request will be sent into the subarea network.  Since this ICN is the SSCP closest to the SLU within its subarea network (the "center" subarea network), it is responsible for choosing the subarea COS name that will be used in this subarea network.  The VTAM ICN uses the APPNTOSA COS Mapping to map the APPN COS name (ACOS) received on the APPN Locate request to an appropriate subarea COS name.  If there is no APPNTOSA COS Mapping table defined or if there is no mapping for this APPN COS name, then the VTAM ICN will use the SLU's MODETAB (or ISTINCLM) to look up the subarea COS name based on the received LOGMODE name (MODE).

NOTE 2:  This is where most customer LOGMODE name and COS name resolution issues occur.  The VTAM that owns the SLU (the NN on the far right) is able to resolve the LOGMODE name and COS names very easily because there is always a definition for the SLU at the owning VTAM node.  At the VTAM ICN, however, the SLU is represented by a CDRSC...and most likely by a dynamically created CDRSC.  Since dynamic CDRSCs do not have a MODETAB associated with them, the IBM default LOGMODE table (ISTINCLM) is typically used.  And since most customers do not modify this LOGMODE table (to include the COS= operand or to include all of their customized LOGMODE names), the received LOGMODE is usually not found.  This results in VTAM using the ISTCOSDF entry from ISTINCLM instead (since the default value for the ISTCOSDF start option allows the ISTCOSDF entry to be used for Independent LUs).  Also, since the COS= operand is not coded on most of the LOGMODE entries in ISTINCLM, the BLANK subarea COS is used for almost all SLU-initiated sessions.

PLU-Side ICN (Request Phase) 

Once the ICN on the right has resolved the subarea COS name (SCOS), it begins adjacent SSCP routing which results in a CDINIT request being sent to the ICN on the left.  This ICN, in turn, decides to search the attached APPN network.  But as the APPN node closest to the OLU (in the left APPN network) , the ICN on the left must choose an APPN COS name before sending this search.  Since the subarea COS (SCOS) was received on the CDINIT request, the ICN on the left will use the SATOAPPN COS Mapping table to choose an APPN COS name.  If an SATOAPPN COS Mapping table does not exist or does not include a mapping for SCOS, then this ICN must use the SLU's MODETAB (or ISTINCLM) to choose an APPN COS name based on the received LOGMODE name (MODE).

NOTE 3:  Again, this is where most customer LOGMODE name and COS name resolution issues occur.  As described above in NOTE 2, this ICN is probably using a dynamic CDRSC to represent the SLU.  This means that the IBM default LOGMODE table (ISTINCLM) is being used, and probably the ISTCOSDF entry within that table.  Since the ISTCOSDF LOGMODE entry has APPNCOS=#CONNECT coded on it, most sessions that are initiated by cross-domain SLUs and enter an APPN network through an ICN use #CONNECT for the APPN COS name.

EN That Owns The PLU (Request Phase) 

After the APPN COS name (ACOS) has been determined by the ICN on the left, an APPN Locate search request is sent into the APPN network to find the partner resource.  When this search request is received by the VTAM that owns the PLU (the EN on the far left), that EN (as the SSCP closest to the SLU within its subarea network) must choose a subarea COS name for the session.  This EN will very likely be using a dynamically created CDRSC to represent the SLU, just as the ICN on the right did, so the processing will be very similar.  (See NOTE 2 above for a description of this processing.)

Response Phase

The flows which follow (the APPN Locate replies and the CDINIT response) normally would not occur in this sequence unless the session becomes queued.  Instead, the PLU node would respond to the SLU-initiated APPN Locate request by sending the BIND toward the SLU immediately.  The flows are shown in this order to reduce confusion and also to show that nothing else of significance (with respect to LOGMODE name and COS name resolution) occurs during these flows for sessions initiated by the SLU.

Chart 10 - APPN-Subarea-APPN PLU-Initiated Session

This chart shows an example of a session that is initiated by the PLU.  The SLU-initiated session was shown first, because the COS Mapping table method of COS name resolution works very intuitively in these cases.  The PLU-initiated session example on this chart demonstrates that, while the COS Mapping table method is still "predictable", it works differently than with SLU-initiated sessions.  As with the previous chart, when the terms MODE, SCOS and ACOS are shown above an arrow (within a Locate or CDINIT signal), this means that the LOGMODE name and/or COS name is included on that signal.  When these terms are shown on one of the ends of an arrow (below a specific node and not within a Locate or CDINIT signal), this means that the node depicted above the term is responsible for resolving the LOGMODE name and/or COS name(s).

EN That Owns The PLU (Request Phase)

When the PLU initiates a session, the VTAM that owns the PLU (the EN on the far left)  begins searching for the partner resource.  However, before this search can be sent into the APPN network (in the form of an APPN Locate request), the APPN COS name must already be determined (since this VTAM is the APPN node closest to the OLU).  Before choosing an APPN COS name, the LOGMODE name must be determined.  If the PLU provided a LOGMODE name on the session initiation request, then this LOGMODE name will be used for the session.  However, if the PLU did not provide a LOGMODE name (a BLANK LOGMODE was provided), then this VTAM must choose a default LOGMODE name for the session.  The default LOGMODE name is determined by the SLU's DLOGMOD value (if specified) or by using the first LOGMODE entry in the SLU's MODETAB (or ISTINCLM).

NOTE 1:  This is where most customer LOGMODE name and COS name resolution issues occur.  At the VTAM that owns the PLU, the SLU is represented by a CDRSC...and most likely by a dynamically created CDRSC.  Since dynamic CDRSCs do not have a MODETAB associated with them, the IBM default LOGMODE table (ISTINCLM) is typically used.  And since most customers do not modify ISTINCLM (to include the COS= operand or to include their customized LOGMODE names), the LOGMODE name provided by the PLU is usually not found in ISTINCLM and the ISTCOSDF entry is used instead.  If the PLU does not provide a LOGMODE name, then the first LOGMODE entry in ISTINCLM is used as the default LOGMODE name for this session (because dynamic CDRSCs typically do not have a DLOGMOD associated with them either).  Either way, the LOGMODE entry that is used for this session is probably not the entry that was intended.

Once the LOGMODE name has been determined, then APPN COS name resolution can be performed.  If COS Mapping tables have not been defined, then the LOGMODE table method is used to choose the APPN COS for this session.  Based on the previous paragraph, the LOGMODE entry used for PLU-initiated sessions will typically be either the ISTCOSDF entry in ISTINCLM or the first LOGMODE entry in ISTINCLM.  So the APPN COS name that would be chosen (if the LOGMODE table method is used) is either #INTER or #CONNECT respectively.  However, if COS Mapping tables are defined, things work a bit differently because a subarea COS name has not yet been chosen.  As described on a previous chart, the LOGMODE table method is always used to resolve the very first COS name, and it is always the subarea COS name that is resolved first.  Assuming one of the previously mentioned LOGMODE entries from ISTINCLM is chosen for this session, the resolved subarea COS name will always be the BLANK COS (since COS= is not coded on most of the LOGMODE entries in ISTINCLM).  After the subarea COS name is resolved, the SATOAPPN COS Mapping table is used to map the subarea COS name to an appropriate APPN COS name (usually #CONNECT).

Once the APPN COS name (ACOS) has been resolved, this VTAM begins searching for the partner resource by sending an APPN Locate search request into the network.  However, if a BLANK LOGMODE name was provided by the PLU, the BLANK LOGMODE name is included on the APPN Locate search.  (The LOGMODE name that was chosen by this VTAM is only used to resolve the APPN and/or subarea COS names.  It is not forwarded on the APPN Locate request, because only the VTAM that actually owns the SLU is allowed to replace the BLANK LOGMODE name with the SLU's default LOGMODE name.) 

PLU-Side ICN (Request Phase)

When the APPN Locate search request is received by the ICN in that APPN network (the ICN on the left), the search is sent into the subarea network.  Now one might think that this ICN would use the APPNTOSA COS Mapping table to map the received APPN COS name (ACOS) to an appropriate subarea COS name.  But recall that the subarea COS name is always resolved at the SLU-side of the subarea network.  Since the receiving ICN (on the left) is on the PLU-side of this subarea network, this ICN is not responsible for resolving the subarea COS name.  Instead, the CDINIT request that is sent through the subarea network will include only the LOGMODE name (which would still be BLANK, if the PLU did not provide a LOGMODE name).

SLU-Side ICN (Request Phase)

When the CDINIT RU is received by the ICN on the right, the search is sent into the APPN network.  But before the APPN Locate search can be sent, the APPN COS name for this APPN network must be chosen.  This ICN is in the same predicament as the VTAM that owns the PLU (the EN on the far left), because it must resolve the APPN COS name using only the received LOGMODE name (which may be BLANK).  As such, this ICN performs the same logic that was performed by the EN(PLU).  This means choosing a default LOGMODE name (if a BLANK LOGMODE was received), and either using the LOGMODE table method to choose the APPN COS name, or using the LOGMODE table method to choose the very first (subarea) COS name and then using the COS Mapping table method to map this subarea COS name to an appropriate APPN COS name.  (See the description for "EN That Owns The PLU (Request Phase)" above for more details.)

Once the APPN COS name (ACOS) has been resolved, the ICN (on the right) begins searching for the partner resource by sending a Locate search request into the APPN network.  And if a BLANK LOGMODE name was provided by the PLU, then the BLANK LOGMODE name is included on the APPN Locate search.

NN That Owns The SLU (Request Phase/Response Phase)

When the APPN Locate search is received by the VTAM that owns the SLU (the NN on the far right), this VTAM is responsible for choosing the subarea COS name that will be used internally within that NN.  (This is different than what happens when the APPN Locate was received by the ICN on the left, because this ICN is not the SSCP closest to the SLU within that subarea network.)  Prior to resolving the subarea COS name, if the received LOGMODE name was BLANK, then this VTAM (as the SSCP that owns the SLU) chooses the default LOGMODE name for the session.  But because this VTAM owns the SLU, the SLU definition is probably not a dynamic CDRSC; rather, it is more likely to be an APPL or  LU, and probably has MODETAB and/or DLOGMOD specified.  So the default LOGMODE name, which is chosen based on the SLU's DLOGMOD value (if specified) or the first entry in the SLU's LOGMODE table (or ISTINCLM), will likely be chosen correctly at this VTAM.  Also, since this is the VTAM that owns the SLU, the default LOGMODE name replaces the BLANK LOGMODE name that was received and is returned to the OLU on the APPN Locate reply (see the Response Phase flows).

Once the LOGMODE name has been resolved (if necessary), the subarea COS name can be chosen.  In this case, the APPN COS name (ACOS) is already known to this VTAM because it was received on the APPN Locate request.  If an APPNTOSA COS Mapping tables exists, then it is used to map the received APPN COS name to an appropriate subarea COS name.  If an APPNTOSA COS Mapping table does not exist (or it does not include a direct or default mapping for the received APPN COS name), then the LOGMODE table method is used to choose the subarea COS name for this session based on the LOGMODE name.

NOTE 2:  If the LOGMODE table method is used by the VTAM that owns the SLU, then the correct subarea COS name will probably be chosen, since the correct MODETAB and DLOGMOD values are known to this VTAM.  If, however, the COS Mapping table method is used by the VTAM that owns the SLU, then the correct subarea COS name may not be chosen.  This is because the subarea COS name would be resolved by COS Mapping the received APPN COS name, which was chosen by some other node (usually) using the wrong MODETAB and/or DLOGMOD values.  This is one reason why the LOGMODE table method is considered to be more "predictable" than the COS Mapping table method.

After successfully processing the received APPN Locate and resolving the LOGMODE name and subarea COS name, the VTAM that owns the SLU returns a positive APPN Locate reply toward the OLU.  As mentioned earlier, the resolved default LOGMODE name (MODE) is returned on this reply.  (The subarea COS name is not needed by the APPN network, so it is not returned.  The APPN COS name does not have to be returned either, since it was provided on the original APPN Locate request.)

SLU-Side ICN (Response Phase)

When the APPN Locate reply is received by the ICN on the right, it must return a positive CDINIT response toward the OLU.  As the SSCP closest to the SLU in this subarea network, the subarea COS name must be returned on this response.  In a pure subarea network, it is at this point that the subarea COS name would normally be chosen.  So in a mixed subarea/APPN network, the subarea COS name is chosen at this point as well (even though a subarea COS name may have already been "looked up" during Request Phase processing in order to resolve the APPN COS name).  This may seem unnecessary or even useless.  However, recall that, if the OLU=PLU provided a BLANK LOGMODE name, then the actual LOGMODE name (as resolved by the VTAM that owns the SLU) was not known to this VTAM ICN until the APPN Locate reply is received.  By waiting to choose the subarea COS name (for use within this subarea network) until the real LOGMODE name is returned, this VTAM ICN can choose the subarea COS name based on the real LOGMODE name, rather than the BLANK LOGMODE.

NOTE 3:  The previous paragraph explains why subarea COS name resolution (for PLU-initiated sessions) is always deferred until Response Phase processing is performed.  However, subarea COS name resolution will still only work as expected if other considerations have also been taken into account.  First, since only the LOGMODE table method uses the LOGMODE name to resolve COS names, the logic described above will only choose the correct subarea COS name (during Response Phase processing) if the LOGMODE table method is used.  Second, in order to choose the correct subarea COS name using the LOGMODE table method, the resolved LOGMODE name must be found in the SLU's MODETAB (or ISTINCLM).  If the SLU is represented by a dynamic CDRSC at this ICN, then ISTINCLM is probably the LOGMODE table that will be used.  And since COS= is not coded on most of the LOGMODE entries in ISTINCLM, the BLANK subarea COS will probably still be used for the session.

NOTE 4:  If an APPNTOSA COS Mapping table is defined at this ICN, then the COS Mapping table method will be used to choose the subarea COS name for the session during Response Phase processing.  This means the SATOAPPN COS Mapping table could be used during Request Phase processing to choose the APPN COS name, and the APPNTOSA COS Mapping table could be used during Response Phase processing to choose the subarea COS name (even though a subarea COS name was "looked up" during Request Phase processing in order to resolve the APPN COS name).  The net result is that this ICN could map "from subarea COS name to APPN COS name and then back to subarea COS name" for the same session.  If the initial subarea COS name is chosen correctly (and assuming the SATOAPPN and APPNTOSA COS Mapping tables are defined with reasonable mappings), this should not cause any problems.  However, if the initial subarea COS name is not chosen correctly (because the SLU definition does not have the correct MODETAB and/or DLOGMOD associated with it), then this could cause what seems to be unpredictable results.  (And these unpredictable results might seem even more unpredictable, if the SATOAPPN and APPNTOSA COS Mapping tables are not defined with reasonable mappings in both directions.)

PLU-Side ICN (Response Phase)

Once the subarea COS name has been resolved, a CDINIT response which includes the real LOGMODE name (MODE) and subarea COS name (SCOS) is returned toward the OLU.  When the ICN on the left receives the CDINIT response, it saves the real LOGMODE name and subarea COS name and then forwards the response (in the form of an APPN Locate reply) back toward the OLU.  The APPN Locate reply includes the real LOGMODE name (as resolved by the VTAM that owns the SLU), but not the subarea COS name (because it is not needed by the APPN network) or the APPN COS name (because it was provided on the original APPN Locate request).

EN That Owns The PLU (Response Phase)

When the APPN Locate reply is received by the VTAM that owns the PLU (the EN on the far left), the same response processing as that performed by the ICN on the right occurs.  That is, as the SSCP closest to the SLU in this (single node) subarea network, the subarea COS name must be resolved, even though a subarea COS name may have already been "looked up" before sending the APPN Locate request.  (See the description of "SLU-Side ICN (Response Phase)" above for more details.)

Chart 11 - Mixed Network Summary 

As the previous two charts demonstrate, LOGMODE name and COS name resolution in mixed subarea/APPN networks is a complicated subject.  Much of the complexity is due to the differences in two architectures (subarea versus APPN), where each network must follow the rules for that type of network.  But in providing support for all existing VTAM functions across APPN (and mixed subarea/APPN) networks, VTAM contributes to this complexity by:

a.	allowing different resources to use different MODETABs (rather than requiring all resources to use the same MODETAB, as other APPN products do),
b.	having special logic to handle cases where the OLU=PLU provides a BLANK LOGMODE name,
c.	not associating any MODETAB and/or DLOGMOD value with dynamically created resources (CDRSCs), and 
d.	providing two methods of resolving subarea and APPN COS names (the LOGMODE table method and the COS Mapping table method).

For sessions initiated by the SLU, LOGMODE name and COS name resolution works very much as one might expect for several reasons.  First, a real (non-BLANK) LOGMODE name is chosen by the node that owns the OLU before sending the search request to any other nodes.  This allows every node that is responsible for resolving subarea and/or APPN COS names to choose them based on the real LOGMODE name.  Second, the subarea and APPN COS names are both chosen at the same logical time during session establishment (that is, during Requst Phase processing).  Finally, since the APPN COS name is chosen at the OLU-side of the APPN network and the subarea COS name is chosen at the SLU-side of the subarea network, the subarea and APPN COS names are both chosen on the same "side" of each network (the OLU=SLU side).  This means that, if SATOAPPN and APPNTOSA COS Mapping tables are defined at each VTAM, COS Mapping works very intuitively for SLU-initiated sessions.  This is due to the fact that, at each subarea/APPN network boundary when a search request is received from either the APPN or subarea network, the COS name for that network is already known.  Since the interchange node at each network boundary is responsible for resolving the COS name for the "next" network, COS Mapping tables can be used very effectively without having to associate MODETABs or DLOGMODs with every CDRSC.

For sessions initiated by the PLU, LOGMODE name and COS name resolution is not as intuitive.  First, the LOGMODE name for the session may be chosen by either the OLU  or the DLU (if the OLU provides a BLANK LOGMODE name).  Because the APPN COS name must be resolved before sending the search, at least some COS name resolution must be performed using the BLANK LOGMODE name.  Second, the subarea and APPN COS names are chosen at different times during session establishment; the APPN COS name is chosen during the Request Phase, while the subarea COS name is chosen during the Response Phase.  When PLUs provide a BLANK LOGMODE name, the APPN COS name is resolved while the LOGMODE name is still BLANK, while the subarea COS name is resolved after the real LOGMODE name is known.  Finally, COS Mapping does not work as one might expect due to which "node role" is responsible for resolving the APPN and subarea COS names.  The end result can be the same node mapping a resolved subarea COS name to an APPN COS name during the Request Phase, and then mapping the APPN COS name back to a subarea COS name during the Response Phase.

Chart 12 - Mixed Network Considerations

The next few charts describe VTAM functions and/or enhancements that give customers more control over LOGMODE name and COS name resolution in mixed subarea/APPN networks.  Before describing these functions and enhancements, it is important to understand what types of issues should be considered.  This chart summarizes the LOGMODE name and COS name resolution issues that all customers should consider when migrating from subarea to APPN networking.

COS Names Chosen Outside SLU Domain

VTAM always chooses LOGMODE names and COS names based on the SLU's definition.  (That is, using the SLU's  MODETAB and/or DLOGMOD values.)  In a pure subarea network, the real LOGMODE name (if BLANK) and the subarea COS name are always chosen by the VTAM that owns the SLU.  Since the owning VTAM almost always predefines the SLU (typically as an LU or APPL), MODETAB and DLOGMOD values can be specified quite easily.

In mixed subarea/APPN networks, it is not always the VTAM that owns the SLU that must resolve the COS names.  In VTAMs that do not own the SLU, the SLU is represented as a CDRSC...and usually by a dynamically created CDRSC.  Since dynamic CDRSCs typically do not have MODETAB or DLOGMOD values associated with them, VTAM uses the IBM-supplied default LOGMODE table (ISTINCLM) as the MODETAB, and uses the first entry in ISTINCLM as the DLOGMOD.  Also, since most customers do not update ISTINCLM with their own customized LOGMODE names, the default LOGMODE entry (ISTCOSDF) is often used instead of the desired LOGMODE entry. 

COS Mapping For PLU-Initiated Sessions Is Not Intuitive

Although the COS Mapping table method of COS resolution works very intuitively for SLU-initiated sessions (where the subarea and APPN COS names are both resolved at the OLU=SLU side of each network), COS Mapping does not work as intuitively for PLU-initiated sessions.  If COS Mapping tables are defined in both directions (SATOAPPN and APPNTOSA), this can result in subarea-to-APPN COS name mapping during Request Phase processing, followed by APPN-to-subarea COS name mapping at the same node during the Response Phase processing.  The end result of this subarea-to-APPN-to-subarea COS name mapping may be that a different subarea COS name is chosen using the COS Mapping table method than was originally chosen using the LOGMODE table method.

PLU=OLU Does Not Always Provide LOGMODE

Because VTAM allows the OLU=PLU to provide a BLANK LOGMODE name (thereby allowing the VTAM that owns the SLU to choose and return a default LOGMODE name on the search reply) and because APPN requires that the APPN COS name be included on the initial Locate request, the APPN COS name will always be chosen based on the BLANK LOGMODE name.  Choosing the subarea COS name, on the other hand, is deferred until after the real LOGMODE name has been resolved by the SLU's VTAM.  However, if APPNTOSA COS Mapping tables are defined, then COS Mapping will be used to choose the subarea COS name.  Since COS Mapping does not use the LOGMODE name, knowing the real LOGMODE name for the session does not help in this case.

One final word of caution:  WATCH FOR UNEXPECTED RESULTS!!!  Because VTAM provides ways to tolerate unrecognized LOGMODE names and COS names without generating error messages, it is quite common for customers to be unaware that they have LOGMODE name and COS name resolution issues.  The only way to know for sure is to LOOK at the results after a session is established.  (Some Debug Aids have been provided on later charts to help with this.)

Chart 13 - Mixed Network Solutions

This chart describes possible solutions to the Mixed Network Considerations described on the previous chart.  In general, these solutions address how to ensure that the correct LOGMODE names and/or COS names are chosen by each VTAM that must resolved them, regardless of whether or not that VTAM owns the SLU.

Predefine All Resources As CDRSCs In Other Nodes

Since most LOGMODE name and COS name resolution issues are caused by VTAM choosing the wrong default LOGMODE name, LOGMODE table or LOGMODE table entry, the most simplistic way to resolve these issues is to predefine every non-local resource in the network as a cross-domain resource (CDRSC) at every node, and include the MODETAB= and DLOGMOD= operands on these definitions.  With this approach, customers can instruct VTAM to use one of their own customized LOGMODE tables for these resources, rather than the IBM-supplied default LOGMODE table (ISTINCLM).  

For most customers, however, predefining everything in the network at every node is not only impractical, it is usually impossible (for example, because they are not aware of all independent LUs and/or customer-attached LUs which use their network for sessions).  Furthermore, the administrative overhead of adding new CDRSC definitions to every host whenever new devices or applications are rolled-out would be a huge burden (and not at all what customers feel they were promised by the "definition-less" APPN architecture).  For these reasons, it is expected that very few customers will use this approach.

NOTE:  Although this approach also allows customers to continue using "resource-specific LOGMODE tables" (that is, different LOGMODE tables for different resources) if they so choose, this is not recommended and, in fact, is impossible to achieve for dynamically created CDRSCs.  Customers will be much better served if, as part of their pre-migration preparation, they create a single LOGMODE table that contains all of the LOGMODE entries from all of their existing LOGMODE tables.  This common LOGMODE table can then be used for all resources (or, at the very least, for all CDRSCs), which is much more in keeping with the way the APPN Architecture was implemented on other platforms.

Modify ISTINCLM As Necessary (At All Nodes)

Because the IBM-supplied default LOGMODE table (ISTINCLM) is used by VTAM for all resources that do not have an explicit MODETAB specified, a second possible solution would be to modify ISTINCLM so that the correct APPN and subarea COS names are chosen.  This means adding new LOGMODE entries for all user-defined LOGMODE names, as well as coding the COS= and APPNCOS= operands on all of the LOGMODE entries in ISTINCLM (including the entries that are shipped with VTAM which have only the APPNCOS= operand coded).

The net result of this approach is that the customer has defined a common LOGMODE table that can be used for all resources (or, at the very least, for dynamic CDRSCs) without requiring that cross-domain resources be predefined with MODETAB and/or DLOGMOD.  However, over the years most customers have been told not to modify ISTINCLM, but to define one or more customized LOGMODE tables instead.  (This way, the customer does not have to re-modify the IBM-supplied LOGMODE table each time a new release of VTAM is installed!)  The ideal solution is a combination of these two approaches; that is, provide a way for customers to use a customized LOGMODE table (rather than ISTINCLM) for cross-domain resources without requiring predefinition.

Use DYNMODTB And DYNDLGMD Start Options

This approach combines the advantages of the two previous approaches, while eliminating many of the disadvantages.  It still requires that customers create a single LOGMODE table that contains all of the LOGMODE entries from all of their existing LOGMODE tables.  However, once this has been accomplished, this single LOGMODE table can be used for all dynamic CDRSCs (without requiring predefinition) by specifying the name of this LOGMODE table as the DYNMODTB start option value at all VTAM nodes.  And to resolve issues that result from the PLU=OLU not providing a LOGMODE name, the DYNDLGMD start option can be used to specify which LOGMODE entry within this LOGMODE table should be used as the default LOGMODE name (DLOGMOD) for dynamic CDRSCs.  (The values for both of these start options can be changed without restarting VTAM by using the MODIFY VTAMOPTS command.)

NOTE:  The DYNMODTB and DYNDLGMD start options do not affect which LOGMODE table and/or default LOGMODE name are used for predefined CDRSCs; these start options only affect dynamic CDRSCs.  However, if CDRSCs are predefined, then customers can use the MODETAB= and/or DLOGMOD=  operands to specify which LOGMODE table and/or default LOGMODE name should be used for these CDRSCs.  To make this even easier, the MODETAB= and DLOGMOD= operand can be coded on one or more GROUP statements within CDRSC major nodes, rather than coding these operands on every CDRSC definition.

Use COS Mapping Tables Instead?  Maybe Not...

As mentioned previously, COS Mapping tables provide a method of resolving subarea and/or APPN COS names without using a LOGMODE name or LOGMODE table.  This is accomplished by mapping an already known APPN or subarea COS name to an equivalent subarea or APPN COS name, respectively.  Although some customers feel that using COS Mapping tables is an easy way to avoid consolidating their LOGMODE tables into a single combined LOGMODE table, this is actually not the case.  As demonstrated by the flows on earlier charts, COS Mapping tables work very well for sessions that are initiated by the SLU; but COS Mapping tables do not work as well for sessions initiated by the PLU.  Also, COS mapping tables do not work well unless the very first (subarea) COS name is chosen correctly, which is always done using the LOGMODE table method.

For these reasons, some amount of LOGMODE table work must be done anyway in order to achieve the desired results.  This includes:

a.	copying all existing LOGMODE entries in customized LOGMODE tables to a single LOGMODE table, 
b.	ensuring that appropriate COS= and APPNCOS= values are specified for each LOGMODE entry in this table, and 
c.	ensuring that this LOGMODE table is used for all CDRSCs, predefined or dynamic.
Once this task is accomplished, very little additional work is required in order to use the LOGMODE table method to resolve the LOGMODE name to appropriate APPN and/or subarea COS names all of the time.  (The only additional work needed is to make sure that an appropriate default LOGMODE name is used to resolve the correct COS names when the OLU=PLU does not provide a LOGMODE name, and this can be accomplished using the DYNDLGMD start option for dynamic CDRSCs or the DLOGMOD operand for predefined CDRSCs.)

NOTE:  When establishing HPR sessions, an APPNTOSA COS Mapping table is still required to resolve the subarea COS name that should be used for the subarea portions of any RTP pipes.  This is due to the fact that many sessions involving many different SLUs may be traversing the same RTP pipe (as long as all of the sessions use the same APPN COS name).  So when RTP Path Switch processing is performed, VTAM does not know which SLU's LOGMODE table should be used to choose the appropriate subarea COS name when the RTP pipe must traverse a subarea VR.  (In fact, during RTP Path Switch processing, intermediate nodes on the RTP pipe are not even aware of which SLUs use the RTP pipe.)  For this reason, VTAM always uses the APPNTOSA COS Mapping table to resolve the subarea COS name for RTPs that traverse subarea VRs; and not just during RTP Path Switch processing, but even when RTPs are initially established.  If an APPNTOSA COS Mapping table has not been defined, then VTAM always uses ISTVTCOS as the subarea COS name, because this is the only standard subarea COS name defined by the subarea architecture.

Chart 14 - Other Potential Issues

The next three charts describe other common LOGMODE name or COS name resolution issues and how they can be avoided or resolved.  The first chart describes how to avoid session failures resulting from unknown LOGMODE names and/or COS names.  Although these types of session failures usually indicate a larger problem (like LOGMODE table issues or the lack of coordinated LOGMODE table and/or COS table definitions across all nodes/products in the network), several customers have expressed the desire to have these sessions be established successfully (regardless of what LOGMODE name or COS names are used), after which they will worry about fixing any LOGMODE name and COS name resolution issues.  

VTAM provides the following start options and definition operands that allow session establishment to continue even when unrecognized LOGMODE names, APPN COS names and/or subarea COS names are received or resolved.  Before going into the details, it is important to distinguish between "unresolved COS names" and "unknown COS names".  If the process of choosing (for example) a subarea COS name fails, then the subarea COS name is "unresolved".  If, however, the subarea COS name has been resolved successfully, but the VTAM that is responsible for choosing the session path (VR) cannot find a matching subarea COS table definition (VR list), then the resolved subarea COS name is "unknown".

Unknown LOGMODE Names

VTAM uses the LOGMODE name to derive various session parameters for the session (e.g., COS names, RU sizes, pacing values, etc.)  When attempting to resolve these session parameters, VTAM always looks up the LOGMODE name in the SLU's LOGMODE table (MODETAB).  If the specified LOGMODE name is not found in the SLU's LOGMODE table, then VTAM will always try to find it in the IBM-supplied default LOGMODE table, ISTINCLM.  If both of these attempts to look up the LOGMODE name fail, then VTAM normally fails the session.

To avoid session failures resulting from unknown LOGMODE names, VTAM must be allowed to derive these session parameters using some other (known) LOGMODE entry.  The LOGMODE entry that VTAM uses by default when it cannot find a matching LOGMODE entry is the ISTCOSDF LOGMODE entry.  If VTAM is allowed to use the default LOGMODE entry (see later), then VTAM will first try to find an ISTCOSDF LOGMODE entry in the SLU's LOGMODE table.  If VTAM cannot find an ISTCOSDF LOGMODE entry in the SLU's LOGMODE table, then VTAM will try to find it in the IBM-supplied default LOGMODE table, ISTINCLM.  

NOTE:  Unless ISTINCLM has been modified by the customer, this final lookup will always succeed, since VTAM ships ISTINCLM with an ISTCOSDF LOGMODE entry included.  But customers can override the ISTCOSDF LOGMODE entry in ISTINCLM, if they so choose.  This can be done either by coding an ISTCOSDF LOGMODE entry in their own customized LOGMODE table(s), or by changing the ISTCOSDF entry in ISTINCLM, reassembling it and restarting VTAM.

When is VTAM allowed to use the default LOGMODE entry, ISTCOSDF?  It depends on what type of resource the SLU is (application, dependent LU or independent LU), as well as the current setting of the ISTCOSDF start option.  The ISTCOSDF start option can be specified as ALL, NONE, or any combination of APPL, DEPLU and/or INDLU (which correspond to APPLs, LUs and CDRSCs respectively).  The default value for the ISTCOSDF start option is INDLU, which means that unless this start option value is explicitly specified or MODIFYed, VTAM will always (and only) be allowed to use the ISTCOSDF LOGMODE entry by default for independent LUs (CDRSCs).

NOTE:  When deciding whether the ISTCOSDF LOGMODE entry can be used for a particular session, the VTAM that performs the LOGMODE table lookup uses it's own representation of the SLU to make this determination.  For example, an application (or dependent LU) that resides on VTAM1 is represented by a CDRSC on VTAM2.  If this resource is the SLU and VTAM2 must decide whether the ISTCOSDF LOGMODE entry can be used, it checks to see if the ISTCOSDF start option value includes INDLU (Independent LUs/CDRSCs), since that is how the SLU is represented in VTAM2.  VTAM2 has no way of knowing whether this CDRSC actually represents an application or a dependent LU in the owning VTAM (VTAM1).

Unknown Subarea COS Names

When a subarea COS name has been resolved and VTAM must derive the list of possible session paths (VRs) for the session, the subarea COS name is looked up in the subarea COS definition table, ISTSDCOS.  If the resolved subarea COS name is not found in ISTSDCOS, then VTAM normally fails the session.

To avoid session failures resulting from unknown subarea COS names, VTAM must be allowed to derive the VR list for the session using some other (known) subarea COS definition in ISTSDCOS.  The default subarea VR list that should be used for unknown subarea COS names is specified by coding the SUBSTUT=YES operand on the appropriate subarea COS table definition (COSTAB entry) in ISTSDCOS.  If SUBSTUT=YES is not coded on any of the subarea COS definitions, then unknown subarea COS names will result in session failures.

Unknown APPN COS Names

When an APPN COS name has been resolved and VTAM must compute the session path (RSCV) for the session, the APPN COS name is looked up in the APPN COS definition table (the COSAPPN member of VTAMLST).  If the resolved APPN COS name is not found in the COSAPPN VTAMLST member, then VTAM normally fails the session.

To avoid session failures resulting from unknown APPN COS names, VTAM must be allowed to compute the RSCV for the session using some other (known) APPN COS definition.  The default APPN COS definition that should be used for unknown APPN COS names is specified using the APPNCOS= start option.  If APPNCOS=NONE is specified (or allowed to default), then unknown APPN COS names will result in session failures.  (Session failures will also occur if there is no APPN COS definition in the COSAPPN member of VTAMLST for the APPN COS name specified by the APPNCOS= start option.)

Chart 15 - Other Potential Issues

LOGMODE Table Issues

This section describes two other common LOGMODE table issues experienced by customers that use LOGMODE tables which do not have either the COS= operand or the APPNCOS= operand specified on one or more LOGMODE table entries.  The logic described below is documented in both the VTAM (CS For OS/390 SNA) Network Implementation Guide and Resource Definition Reference.

The most common of these two issues involves LOGMODE entries that do not have the COS= operand coded.  Since most customers have been using subarea networking for quite some time, one might think that this issue does not occur very often.  But this happens to be the way most of the LOGMODE table entries in the IBM-supplied default LOGMODE table (ISTINCLM) are coded when VTAM is shipped.  Because customers (who do not specify the DYNMODTB start option) do not realize that ISTINCLM is being used by VTAM for all dynamically created CDRSCs (and any predefined CDRSCs that do not have MODETAB= specified),  they also do not realize that the missing COS= operand on these  LOGMODE entries results in the BLANK subarea COS name being used for almost all sessions.  This issue can be avoided by either modifying ISTINCLM to include the COS= operand (and then reassembling ISTINCLM and restarting VTAM) or by coding the DYNMODTB start option (for dynamic CDRSCs) and the MODETAB operand (for predefined CDRSCs) so that a different LOGMODE table is used.

The second of these two issues results when the APPNCOS= operand is not coded on one or more LOGMODE table entries.  When neither the COS= operand nor the APPNCOS= operand is specified, then #CONNECT is always used as the APPN COS name for that LOGMODE entry.  However, when the APPNCOS= operand is not specified but the COS= operand is specified, VTAM assumes that the subarea COS name is also a known APPN COS name.  This means that VTAM will try to find a COS definition for the subarea COS name inside the APPN COS definition table (the COSAPPN member of VTAMLST).  Since the APPN COS definition table that is shipped with VTAM only contains definitions for the standard APPN COS names (#INTER, #CONNECT, #BATCH, CPSVCMG, etc.), subarea COS names typically are not found within this table.  This means that sessions will either always use the APPN COS name specified by the APPNCOS= start option, or they will fail (if APPNCOS=NONE is specified or allowed to default).  This issue can be avoided by ensuring that both COS= and APPNCOS= are specified on all LOGMODE entries in all LOGMODE tables.

APPNTOSA COS Mapping Table Required For HPR Over VRs

As mentioned earlier, when establishing HPR sessions, an APPNTOSA COS Mapping table is still required to resolve the subarea COS name that should be used for the subarea portions of any RTP pipes.  This is due to the fact that many sessions involving many different SLUs may be traversing the same RTP pipe (as long as all of the sessions use the same APPN COS name).  So when RTP Path Switch processing is performed, VTAM does not know which SLU's LOGMODE table should be used to choose the appropriate subarea COS name when the RTP pipe must traverse a subarea VR.  (In fact, during RTP Path Switch processing, intermediate nodes on the RTP pipe are not even aware of which SLUs use the RTP.)  For this reason, VTAM always uses the APPNTOSA COS Mapping table to resolve the subarea COS name for RTPs that traverse subarea VRs; and not just during RTP Path Switch processing, but even when RTPs are initially established.  If an APPNTOSA COS Mapping table has not been defined, then VTAM always uses ISTVTCOS as the subarea COS name, because this is the only standard subarea COS name defined by the subarea architecture.

Note that once the APPNTOSA COS Mapping table is defined, it will be used (in preference to the LOGMODE table method) during LU-LU session establishment to resolve the subarea COS name (from the APPN COS name, if known).  This should not cause any problems, however, assuming that the APPNTOSA COS Mapping table is defined with reasonable COS mappings.

Chart 16 - Other Potential Issues

This chart describes one final potential issue related to sessions established with the VTAM host CP (which has now been fixed by APAR OW26928).  When establishing sessions with the host CP (such as CPSVCMG or CP-CP sessions, and CPSVRMGR or DLUR/DLUS sessions), the host CP must be represented internally by an RDTE that is LU-LU session capable.  Because the host CP exploits the APPC application programming interface, the decision was made to represent the host CP as an APPL (application) RDTE.  VTAM creates this APPL RDTE automatically at VTAM startup whenever the NODETYPE= operand is coded (i.e., APPN has been enabled).  Because this RDTE is created by VTAM dynamically, the customer has no opportunity to code the MODETAB= operand.  This results in the IBM-supplied default LOGMODE table (ISTINCLM) being used for all sessions to this host CP.  This does not cause any problems when using the LOGMODE name to resolve the APPN COS name, because all of the LOGMODE entries in ISTINCLM have APPNCOS= coded.  However, if a host CP session must traverse a subarea VR (and, therefore, must resolve a subarea COS name), the BLANK subarea COS name was used because COS= was not coded on any of the LOGMODE entries in ISTINCLM.  This could result in significant performance degradation on sessions to host CP.

One possible circumvention was for customers to use the MODIFY TABLE command (once VTAM initialization was completed) to associate a different LOGMODE table (MODETAB) with the host CP RDTE.  However, if sessions to the host CP were started automatically, they would have to be recycled after issuing the MODIFY TABLE command in order to pick up the changes.  

The second possible circumvention was for customers to modify ISTINCLM to include the COS= operand on the LOGMODE entries used for host CP sessions (the CPSVCMG and CPSVRMGR LOGMODE entries), and then reassemble ISTINCLM and restart VTAM.  In fact, it is this "circumvention" that eventually became the official "solution" to this problem.  APAR OW26928 adds the COS=ISTVTCOS operand to the above mentioned LOGMODE entries in ISTINCLM.  Since ISTVTCOS is the only standard subarea COS name, all customers should have a subarea COS definition for ISTVTCOS.  And since ISTVTCOS is the subarea COS name that is used for all SSCP sessions (like SSCP-PU, SSCP-LU and SSCP-SSCP), it makes sense that host CP sessions should use this same subarea COS name.

Chart 17 - Debug Aids:  DISPLAY SESSIONS,SID=

As the preceding charts clearly demonstrate, there are many subtle nuances involved when resolving LOGMODE names and COS names in mixed subarea/APPN networks.  If, for performance reasons, choosing the correct subarea and/or APPN COS is critical, then it is very important to examine sample sessions that use various LOGMODE names and COS names (and at various nodes on the session path) to make sure that the correct values are being used.

VTAM displays the LOGMODE name and COS name(s) in the output to the DISPLAY SESSIONS command when the SID= (session ID) operand is specified.  This chart shows two DISPLAY commands that can be used to determine the SID for a specific session.  However, it should be noted that both of these commands have the potential to generate a lot of output, which could hang up the VTAM operator's console for some time.  The following steps can be taken to minimize the amount of output that is generated.

a.	The DISPLAY ID= command displays every active or pending session with the target resource when "Every" (or SCOPE=ALL) is specified.  But the SID for the target session can be obtained by DISPLAYing either of the session partners involved in the session.  To minimize the output generated by this command, it is recommend that the DISPLAY ID= command be issued for the session partner that is expected to have the fewest number of sessions.
b.	The DISPLAY SESSIONS,LIST=ALL command displays every active or pending session known to this VTAM.  However, there are many operands available for the DISPLAY SESSIONS command that minimize the amount of output that is generated.  In particular, the PLU= and/or SLU= operands can be used to significantly reduce the number of sessions that are displayed.  If it is not known whether the target resource was the PLU or SLU of the subject session, then the LU1= operand (and the LU2= operand, if the session partner is also known) can be used to display all sessions with the target resource regardless of session polarity.  (As with the DISPLAY ID command above, it is recommended that, if only one resource name is specified using the PLU=, SLU= or LU1= operands, it should be the session partner that is expected to have the fewest number of sessions.)
The DISPLAY ID= command also displays other useful information that can be used to identify and resolve LOGMODE name and/or COS name resolution issues.  In particular, the MODETAB= and DLOGMOD= values (shown on the IST861I and IST934I messages respectively) show what LOGMODE table and default LOGMODE name are associated with the subject resource (at this VTAM).  If these values are not what is expected, then there may be some definition issues that must be corrected.

One common issue in this area involves CDRSCs that do not seem to inherit the DYNMODTB= and/or DYNDLGMD= start option values.  If this should occur, check the IST231I message to determine in which CDRSC major node the subject CDRSC is defined.  If the CDRSC is defined in any major node other than ISTCDRDY (the "dynamic CDRSC" major node), then this CDRSC was predefined rather than being created dynamically.  Since only dynamic CDRSCs inherit the DYNMODTB and DYNDLGMD start option values, it will be necessary to explicitly code the MODETAB= and/or DLOGMOD= operands for these predefined CDRSCs.

NOTE 1:  If the CDRSC is located within the ISTPDILU major node, then the resource was actually predefined as an LU with LOCADDR=0 and was converted to a CDRSC by VTAM when it was activated.  In this case, the LU definition must be updated to include the MODETAB= and/or DLOGMOD= operands.

NOTE 2:  Rather than changing many CDRSC definitions to include the same values for these operands, the same result can be achieved much more easily by inserting one or more GROUP statements into the CDRSC major node(s) and coding the MODETAB= and/or DLOGMODE= operands on the GROUP statement(s) instead.

Chart 18 - Debug Aids:  DISPLAY SESSIONS,SID=

Once the session ID (SID) for the session has been determined, the DISPLAY SESSIONS,SID= command can be used to display further information about the session, as shown on this chart.  The following are some of the things to look for:

a.	The LOGMODE name chosen for this session is shown on the IST933I message.  
b.	The LOGMODE name shown on IST933I (see above) can be misleading, if it is not defined in either the SLU's MODETAB or ISTINCLM and the ISTCOSDF start option is coded such that the default (ISTCOSDF) LOGMODE entry can be used for this session.  IST1438I is displayed whenever the default LOGMODE entry was used because the actual LOGMODE name could not be found in the SLU's MODETAB or ISTINCLM.
c.	The subarea COS name for the session is also shown on the IST933I message.
d.	The APPN COS name for the session is shown on the IST875I message.  If this VTAM is defined as an APPN Border Node (BN=YES was specified) and the session crosses an APPN network boundary at this BN, then VTAM may learn and save the APPN COS name that was used in the adjacent APPN network, as well as the APPN COS name used in the local APPN network.  When this occurs, two IST875I messages are displayed by VTAM; one showing the APPN COS name used in the PLU direction, and one showing the APPN COS name used in the SLU direction.

List Of Acronyms

APPN - Advanced Peer-to-Peer Networking
APPC - Advanced Program-to-Program Communication
BN - Border Node
CDINIT - Cross-Domain Initiate Request or Response Unit
CNN - Composite Network Node
CMC - Communications Management Configuration
COS - Class Of Service
CP - Control Point
CS For OS/390 - Communications Server For OS/390
CS/390 - Communications Server For OS/390
DH - Data Host
DLU - Destination Logical Unit
DLUR - Dependent Logical Unit Requester
DLUS - Dependent Logical Unit Server
EN - End Node
ER - Explicit Route
HPR - High Performance Routing
ICN - Interchange Node
NN - Network Node
NNS - Network Node Server
OLU - Originating Logical Unit
PLU - Primary Logical Unit (BIND Sender)
RSCV - Route Selection Control Vector
RTP - Rapid Transport Protocol
SLU - Secondary Logical Unit (BIND Receiver)
SNA - Systems Network Architecture
SNI - SNA Network Interconnect
SSCP - System Services Control Point
TGVs - Transmission Group Vectors
VR - Virtual Route
VTAM - Virtual Telecommunications Access Method