Understanding the Session Awareness Interface › NTS Classes

NTS Classes

In a given network, different session types need different types and amounts of data collected by NTS. It is also useful to map this data onto the underlying resource hierarchy.

These objectives are achieved through use of the following types of NTS classes:

• SAW classes
• RTM classes
• Session classes
• Resource classes

When NTS receives a session start notification from VTAM, it determines, from the NTS class definitions, which options are to apply to the session. NTS extracts and stores these options, with other information about the session, for use in subsequent processing. This means that all NTS class definitions should be in place before collection of SAW data is started. Defining classes when SAW processing is active does not affect existing sessions, only new ones.

By default, if no classes are defined to NTS, SAW data only is collected for all sessions. Trace data can also be collected by operator request, but no accounting, RTM, or resource statistics data are collected.

SAW Classes

Each SAW class defined to NTS describes a set of processing options for all SAW information, including whether such information is required.

By default, NTS keeps in storage information concerning every session that is currently active. However, if this is not necessary or is impracticable due to storage restrictions, you must have a SAW class definition with the KEEP=NO option (using the DEFCLASS or REPCLASS command) to prevent NTS from collecting any data for sessions in that class. In this case, no other SAW class options are meaningful; therefore, only one such SAW class definition should be necessary because many session classes can nominate to use the same SAW class definition.

SAW class definitions specify the conditions under which all or any session data is logged to the NTS database at session end. For example, you may want to log session data if an error occurs that terminates the session, or perhaps whenever the operator collects trace data. Various SAW class options exist that cater for these and other requirements.

You can set the initial and final trace queue depths with the SAW class definition. This allows differing amounts of trace data be kept for different sessions.

You can also use SAW classes to determine whether accounting information should be collected when NTS selective accounting is requested (that is, SYSPARMS NTSACCT=SELECTIVE is specified or defaulted).

RTM Classes

NTS lets you collect RTM data for particular sessions. For NTS to collect RTM information from network control units, you must define one or more RTM classes. In addition, it is necessary for the control units (which may be 3274s, 3174s or compatible devices) to have the required RTM hardware or microcode level support for the collection of RTM data and host-modifiable RTM definition configured.

Each RTM class specifies a set of up to four boundary values to use for the collection of RTM data. These boundary values are ascending times in the range 0.1 seconds to 30 minutes. For sessions using the RTM class, these boundary values are set in the control unit for the duration of the session to capture the RTM data.

In addition, for each RTM class an objective response time and an objective percentage value are defined. These values can be used to represent a level of service so that you can compare the measured service level with that specified in a service agreement. You can also define RTM definitions, which are the response criteria that indicate what RTM data is kept.

The objective values are used in performance monitoring for network response times and can lead to attention message creation.

The objective response time must correspond to one of the boundary values allocated for the objective percentage comparison to be accurate. We recommend that the second or third boundary contain the objective value. This lets you observe how the responses are distributed and decide whether to revise the objective value upward or downward.

Note: For an understanding of RTM data collection in the network control units, or their attached distributed function devices, see the relevant component description guides.

Session Classes

Session class definitions provide a dual function. They provide the session selection criteria that determine to which session class each session belongs, and they also provide the SAW and RTM class names from which the sessions falling in each session class should take their SAW and RTM class values. Hence, unless each SAW and RTM class defined is nominated by at least one session class definition, their attributes are never used by NTS.

Session partner names are available as session selection attributes, and the definition for the class can use wild character positions and generic character strings as the criteria to match. Therefore, you can select a specific name, such as an application, or generic names, such as all terminals on a certain line or NCP, and any number of combinations of such names.

Other session selection criteria include the following:

• The Class-Of-Service name (COSNAME) for the session
• A SSCP name
• An Explicit Route (ER) number
• A Virtual Route (VR) number
• The Transmission Path (TP)
• Session type (for example, LU-LU)
• Session class (for example, XDOM)
• The source of the SAW data (SAW data may come from the local VTAM or from a remote VTAM if you are using NTS-SI)

Session classes are defined using the DEFCLASS command.

Session Classification

When NTS receives a new session start notification from VTAM, it searches your session class definitions for the best match. Session attributes are checked in the following order:

• Primary session partner name
• Secondary session partner name
• COSNAME
• ER number
• VR number
• TP

More specific attributes are checked before less specific ones; for example, the name TSO1B is checked before the generic name TSO>. Any attributes not specified are considered wild, and to match any session value.

When a match is found, NTS stores the options defined for the SAW, RTM, and resource class names (if present) with the session data. These options determine the form of subsequent processing for the session.

Next Best Match

If an RTM definition is not supplied for the class with which the session is initially matched, the search continues for an RTM class definition in the next most suitable session class.

Similarly, if a SAW definition is not supplied for the class with which the session is initially matched, the search continues for a SAW class definition in the next most suitable session class.

Session data can therefore be derived from more than one session class. For example, session data can include the following:

• SAW options, derived from the session class that has a matching primary session partner name
• RTM options, derived from the session class that has a matching secondary session partner name

It is also possible to have a session class definition where every attribute is wild (that is, every session matches it). This enables you to supply default SAW or RTM classes for those sessions that do not match any of the more selective session classes.

Session Class Definitions

The following table shows a representation of NTS class definitions, and examples of the NTS class selection process using these definitions.

In this example, names ending with > indicate that any sequence of characters can follow the prefix, and an asterisk in any column represents a don't care condition. Using this example, the NTS class selection process proceeds as follows:

• For a session between CICS and terminal REMA007, the SAW class name CICS and RTM class name CICSREM is selected.
• When a user logs on to TSO from a terminal named LCLB002, an initial session between TSO and LCLB002 is established. It selects the SAW class NOKEEP and the RTM class name RTMLCL. The ensuing session between the TSO target application (named, for example, TSO0019) and LCLB002 uses the SAW class name TSO and the same RTM class name, RTMLCL.
• Any session using the COSNAME ISTVTCOS and ER 0, and not involving CICS and TSO, selects the SAW class name NOLOG.
• A session between NMT and N8L4A01 on ER 1 selects the last entry, yielding a SAW class of SAWDEF and no RTM class.

NTS processes sessions according to your class definitions.

RTM Class Processing

When NTS receives a session for which RTM data is to be collected, the boundary values for that class are set in the control unit and retained for the duration of the session.

The objective response times and objective percentage for the class are used to monitor network response times and automatically generate attention messages.

Resource Classification

To match a resource with a resource class definition, NTS must be aware of the resource and its position in the hierarchy. The time when this occurs depends on the domain in which the resource is defined:

• If the resource is in the same domain as NTS, then NTS becomes aware of the resource and its position in the hierarchy when it receives session data for a session in which the resource is participating.
• If the resource is in another domain, then NTS becomes aware of its hierarchical position only if a suitably configured intersystem routing (ISR) link to the NTS in the other domain exists, and the link is active.

Having been made aware of a resource and its position in the hierarchy, and providing that you have defined at least one resource class, NTS selects the resource class definition that best matches the attributes of the resource. If no class definition matches the attributes of the resource, no data is collected for it.

Resource Levels

The level of the resource class is the level of the hierarchically lowest parameter specified in the class definition. In this context, a link is at a higher level than a PU, which is at a higher level than an LU. Links are said to own PUs that use the link, as well as the LUs that are defined on those PUs. PUs own LUs that are defined on the PU.

A resource matches a resource class if all operands of parameters in the resource class definition are matched by the actual resource in the hierarchy. It is possible for a resource to match more than one resource class definition, but data from one class definition only can be stored for the resource. NTS searches resource class definitions in order from most to least specific, and selects the first resource class definition that matches the attributes of the resource.

Mechanics of Resource-matching

NTS compares resource attributes to the values of resource class definition parameters as follows:

• If an attribute of a resource matches the value of a parameter in more than one resource class definition, then NTS selects the class in which the match is most specific, in the order LU, then PU, then link.
• If higher level parameter values in a resource class definition are matched, then NTS attempts to match resources with resource class definitions at the same level.

  For example, if the resource is an LU, NTS first searches resource class definitions that have the LU parameter as the hierarchically lowest parameter, for a match.

• If the resource does not match any resource class definitions at its own level, then NTS checks to see if there is a resource class at a level above with a member that owns the current resource. If there is more than one, then NTS selects the resource class that is hierarchically closest to the current resource.

  For example, if the resource is an LU, a matching PU-level class is selected before a matching link-level class.

• A resource cannot match a resource class if the level of the resource is higher than the level of the class.

  For example, if the resource is a PU, it cannot match class definitions that have the LU parameter as the hierarchically lowest parameter.

Resource class definitions determine the way NTS processes data for different network resources or groups of resources.