Network Tracking System › Define NTS Classes

Define NTS Classes

Processing performed by NTS is determined by class definitions.

In a given network, there are various different types of sessions and resources. You may want NTS to collect specific types and amounts of data for each different session type, and require different forms of processing for different session types. You may also want to map session data to the underlying resource hierarchy.

You can achieve these objectives by defining the following types of NTS classes to suit your installation needs:

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

By default, only SAW data is collected, and for all sessions, which may not suit your installation. No accounting, RTM, or resource statistics data is collected until you define your classes.

Specify the DEFCLASS Command

To define the attributes of the various categories or classes of session that control how NTS is to collect and process data, use the DEFCLASS command.

For more information about the attributes used to set up the class definitions, see the online help.

To define classes

1. Decide which classes you need and the attributes each class should have.
2. Specify the DEFCLASS SESSION, RESOURCE, SAW, and RTM commands, and appropriate operand values in your initialization procedure (normally $NSINIT).
3. Periodically review the data collected by NTS and adjust any class definitions to suit new requirements.

To subsequently add class definitions, issue a DEFCLASS command from OCS. You must enter all operands, except those that have default values. If you do this while the region is running, the new class definitions do not affect any existing sessions NTS is aware of but are used by any new sessions.

Define Session Classes

Session class definitions provide the following:

• The session selection criteria that determine to which session class each session belongs
• The names of SAW and RTM classes from which the member sessions derive their SAW and RTM class values

Each session class definition contains the following information:

• A unique session class identification name
• Parameters that a session must match, to be considered a member of this session class:
  • Full and partial names of primary and secondary resources
  • The subarea and APPN COS (Class-Of-Service) name for the session
  • An explicit route number and a virtual route number
  • A subarea and an APPN transmission priority
  • The session type and class
  • The source of the session
  • An SSCP name (identifying the domain of origin of the session)
• The names of the SAW and RTM class definitions that can be used by sessions in this class

Valid characters for operands in session classes include the following:

Note: If any session class selection operands are omitted, any value of the omitted parameter is considered valid. For example, if no PRI operand is specified, any primary name is considered valid.

Valid Values for the DEFCLASS SESSION Command Operands

Example: Session Class Definition

The following is an example of a session class definition:

DEFCLASS     SESSION=TSOB  PRI=TSO>  SEC=ASYD>
             SAWCLASS=NOLOG  RTMCLASS=TSO

In this example, the session class is called TSOA. For this class:

• Members are primary resources with a name that commences with the letters TSO, and secondary resources with a name that commences with the letters ASYD.
• Members use SAW class NOLOG, which specifies that session data be retained, but not logged.
• Members use RTM class TSO.

Use Generic Names for Logging

All information logged to the NTS database is session-related and is stored under the session partner names. Together, the two network-qualified session partner names form a session name pair.

To limit the number of session name pairs stored in the NTS database, your session class definition parameters can specify generic session names (or part names), where possible.

For example, an application such as TSO has many ACB names that all begin with a common prefix, TSO>. This means that different sessions between a terminal and various TSO ACBs can all be logged under the same session pair name (that is, TSO>).

Define Resource Classes

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

Resource class definitions contain the following information:

• A unique resource class identification name
• Parameters that resources must match (potentially: specific link, PU, or LU names) to be considered members of the resource class

  Note: At least one of the following must be specified per resource definition: a LINK, PU, or LU name.

• Whether accounting statistics are collected
• A limit range (from 0 to 255) for the number of intervals that can occur before the statistics for the oldest interval are overwritten
• The names of the RTM class definitions that can be used by resources in this class

Valid characters for operands in resource classes include the following:

If you specify parameters other than the parameter that defines the level of the resource class, this has the effect of limiting the range of resources that match the resource class definition.

For example, if you specify the PU and the LU parameters in the same resource class definition, the range of matching LUs is narrowed to those owned by the nominated PU(s). Because all resources should have unique names, this level of detail is worthwhile only if the value of the hierarchically lowest parameter in the class definition is generic, for example: LU=TSO>.

Valid Values for the DEFCLASS RESOURCE Command Operands

Examples: Resource Class Definitions

The following shows two examples of resource class definitions:

DEFCLASS     RESOURCE=ALLINK  LINK=>  STATS=YES
             RTMCLASS=CICS

DEFCLASS     RESOURCE=TSO  LU=TSO>  STATS=YES

In the first example, the resource class is called ALLINK. For this class:

• All links are considered to belong to this class, as indicated by the specification LINK=>.
• Statistics are collected for members of this class.
• Members use RTM class CICS. The format of RTM responses received by a resource are compared to the format defined in this RTM class definition, and statistics kept when a match is found.

In the second example, the resource class is called TSO. For this class:

• All LUs that have names starting with the letters TSO are considered members of this class (LU=TSO>).
• Statistics are collected for members of this class.
• Because no RTMCLASS parameter is specified, no RTM statistics are collected; accounting statistics are, however, still collected.

Define SAW Classes

Each SAW class that you define to NTS describes a set of processing options for all session awareness information, including whether to retain such information. Therefore, SAW classes can be used to ensure that no unwanted session data is collected, thereby saving processing time and storage space.

SAW class definitions contain the following information:

• A unique SAW class identification name
• Whether to collect accounting statistics
• Whether to generate EDS events
• Whether to keep session records
• Whether to log NTS data, and under what conditions
• The depth of the initial and final trace queues

The following table shows the valid operands for the DEFCLASS SAW command, and the valid values for each operand. Default values are underscored.

Examples: SAW Class Definitions

Two examples of SAW class definitions are shown and explained below.

DEFCLASS    SAW=KEEP                 ACCT=YES  KEEP=YES  LOG=ALL
                                               TRACE=(4,20)
DEFCLASS    SAW=NOKEEP               KEEP=NO

In the first example, the SAW class is, aptly, called KEEP. It specifies the following:

• SAW data for sessions with which this class is associated is retained by NTS (KEEP=YES).
• Accounting data is accumulated for sessions with which this class is associated (ACCT=YES).
• All session and SAW data is unconditionally logged (LOG=ALL).
• The trace queue depth is restricted to 4,20 (that is, 4 PIUs in the initial queue and 20 in the final queue).

Associate only the type of sessions for which you specifically wanted to retain all data with this SAW class.

In the second example, the SAW class is called NOKEEP.

Because KEEP=NO is specified, NTS discards SAW data for any sessions with which this class is associated. This means that no information about these sessions is available and no other NTS information can be collected for such sessions; therefore, there is no reason to specify other operands for this class. This avoids the collection of unwanted session data.

Define RTM Classes

To enable NTS to collect RTM information from network control units, you need to define one or more RTM classes. In addition, your control units (which can be 3274s, 3174s, or compatible devices) must have the required RTM hardware or microcode level support for the collection of RTM data, and have a host-modifiable RTM definition configured.

RTM class definitions contain the following information:

• A unique RTM class identification name
• Objective response times for this class
• Percentage of overall responses that must meet the objective response time for this class. Together, the values mean, for example, 90% of responses will be 1.5 seconds or less.
• Collection boundaries to set in the control unit
• Definition criteria, to indicate what RTM data is kept

When NTS receives a session for which RTM data is 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 can lead to the automatic generation of attention messages.

The following table shows the available operands for the DEFCLASS RTM command and the valid values for each operand. Default values are underscored.

Examples

The following shows two examples of RTM class definitions:

DEFCLASS    RTM=CICS  OBJTIME=1.0  OBJPC=90 
            BOUNDS=(0.5, 1.0, 2.0, 5.0)

DEFCLASS    RTM=TSO  OBJTIME=2.0  OBJPC=80 
            BOUNDS=(1.0, 2.0, 5.0, 10.0)  RTMDEF=CDEB

In the first example, the RTM class is called CICS. For this class:

• The objective response time for the session is one second (OBJTIME=1.0).
• The objective percentage for this RTM class is 90 percent (OBJPC=90).
• Four boundary values are set in the control unit and used to accumulate RTM data for each session using this class {BOUNDS=(0.5,1.0,2.0,5.0)}.

Because the RTMDEF operand is not specified, response time is measured until the first character of the host data stream is received (this is the default).

In the second example, the RTM class is called TSO. For this class:

• The objective response time for the session is two seconds (OBJTIME=2.0).
• The objective percentage for this RTM class is 80 percent (OBJPC=80).
• Four boundary values are set in the control unit and used to accumulate RTM data for each session using this class (BOUNDS=(1.0,2.0,5.0,10.0)).
• Response time is measured until an SNA change direction or end bracket order is received (RTMDEF=CDEB).

Modify NTS Class Definitions

After you have been using NTS for a time, you may want to modify one or more NTS class definitions. You would normally do this while session awareness is inactive.

Display Definitions

To display NTS class definitions

1. Use the SHOW DEFCLASS command.
2. Specify the type of class or classes you want to display—session, SAW, RTM, or resource—and, if you want to limit the display, the class name or partial name.

Example: Display Definitions

This is an example of the use of the SHOW DEFCLASS command.

SHOW DEFCLASS RTM=CICS

All RTM classes starting with the letters CICS are listed.

Update Class Definitions

To replace or delete class definitions, use the REPCLASS and DELCLASS commands.

To change one or more attributes of a class, use the REPCLASS command to redefine the entire class. This command shares the same operands as the DEFCLASS command.

Example: Update Class Definitions

To delete the RTM class called CICS, issue the following command:

DELCLASS RTM=CICS