Network Tracking System › Data Available to NTS

Data Available to NTS

The primary objects that concern NTS are network-addressable units, also called resources, and sessions between these resources. The resources can be in the same domain, in different domains, or even in different networks.

The following data types are available to NTS:

• Session awareness (SAW) data, which consists of session start and session end notifications from VTAM
• Session data that contains information about the performance and status of a session, including the following:
  • Session trace data
  • Response time data
  • Route configuration data

Session Awareness Data

VTAM supplies NTS Session Awareness (SAW) data relating to sessions that the local SSCP maintains. This includes data about SSCP-SSCP, SSCP-PU, SSCP-LU, LU-LU and CP-CP sessions.

If linked to other NTS regions, NTS can also receive SAW data from VTAMs in remote domains.

Composition

SAW data consists of the following data:

• Session Identification Data

  Includes the following:

  • Session partner names (or aliases, if applicable) and addresses
  • PCIDs
  • Session start and end time
  • Session type and class (such as: same domain, cross domain)
• Session Connectivity Data

  Includes the following:

  • Explicit Route (ER)
  • Virtual Route (VR) and Transmission Priority (TP) that the session is using
  • Logmode and Class of Service (CoS) table entries the session is using
• Session Hierarchy Data

  Includes the following:

  • Controlling PU name
  • Link name, and subarea PU name (where relevant) for each session partner resource
• Session Exception Data

  Includes the following:

  • Sense codes describing any error conditions that occurred while the session was in progress

Session Trace Data

Through NTS, you can issue requests to VTAM to start tracing sessions that involve resources in the local VTAM domain. As a result, NTS receives trace data from VTAM and associates it with session records in storage. NTS can also solicit trace data collected by VTAMs in other, linked NTS regions.

Composition

Trace data consists of copies of Path Information Units (PIUs) that flow on traced sessions. PIUs are message units that comprise the following:

• A Transmission Header (TH)
• A Request/response Header (RH)
• Any Request/response Unit (RU)

For session control RUs, the entire RU is included; otherwise, for performance reasons, only the first 11 bytes are retained.

For more information about how to obtain extended trace information, see the STRACE command description in the online help.

Response Time Monitoring Data

Response Time Monitoring (RTM) data is a measure of how long it takes for an operation to transmit between a display station and a host.

NTS obtains the response time information from the cluster controller at session end, then associates the response time obtained for a display station with the session record in storage.

Note: For RTM data to be available to NTS, the cluster controller must support host programming.

The cluster controller sends solicited and unsolicited data to NTS. This data originates from PUs that implement RTM (3x74s or equivalent) for their attached LUs.

NTS can also solicit RTM data collected by other NTS regions.

Composition

RTM data received from the cluster controller consists of the following:

• Boundary Values in Seconds

  These boundaries demarcate buckets into which individual response times are counted; an overflow bucket is also provided.

• Bucket Counts

  These counts represent the total number of response times in the specified boundaries since the beginning of the session, or since the response times were last reset.

Route Configuration Data

NTS receives solicited and unsolicited route configuration data from VTAM and other subarea nodes. You can dynamically request ER and VR configuration information from subarea nodes visible to NTS.

Composition

Route configuration information includes the following:

• Source, destination, and adjacent subarea numbers
• Source, destination, and adjacent control point names if the session involves APPN
• The status of the ER, VR, and TP
• Session route information for the current APPN subnetwork if available