When NTS is aware of active sessions and resources, further data can be collected and stored with the appropriate session records in its database.
NTS keeps session records that are flagged to be kept by the matching SAW class only. (The only exception is SSCP-SSCP session records, which are always kept.) Any trace, accounting, or RTM data collected by NTS is stored with the appropriate session record.
NTS stores both resource records and session records in its database. For each session record that is kept, there is always a resource record that represents the session partner. In addition, NTS keeps a record for every resource in the domain of the VTAM host system in which it is running, regardless of whether sessions with that resource are kept or not.
Note: The only way that NTS can be made aware of resources is through SAW. NTS is therefore only aware of resources that are currently active; that is, are involved in an SSCP-PU or an SSCP-LU session. NTS may have database records for additional resources, but each of those resources must have been active at some previous time when NTS was running.
NTS provides a trace monitoring capability that selects and formats trace data (which consists of copies of Path Information Units (PIUs) that flow on traced sessions) for a specific resource as it arrives from VTAM. Trace data is time-stamped by VTAM before being passed to NTS for correlation with other data related to the appropriate session.
NTS stores session establishment PIUs with session records in an initial queue. When this queue is full or when session establishment is complete, subsequent PIUs are placed in a final queue. When the final queue is full, wrap processing occurs (that is, the oldest PIUs are deleted to make way for the newest ones). The depth of the queue is determined by the SAW class definition for the session.
Formatted trace PIUs are directed to a user's OCS screen, the activity log, or both, according to the options you specify. This facility lets an OCS operator closely monitor a particular resource, or an NCL procedure can be written to examine the session data flow.
When a specific resource is being traced, data is collected for all sessions that involve the resource.
If the resource is unknown to NTS when the trace request is issued, the request is nevertheless accepted and passed to VTAM. Provided that the major node to which the resource is defined is currently active, VTAM accepts the request. NTS remembers such requests, which remain in a pending state until the resource is activated.
Similarly, if a resource being traced is deactivated, NTS places the trace request in a pending state until it is reactivated, or until a trace termination request is received.
NTS accounting data is extracted from the trace data supplied by VTAM; therefore, it is dependent on the capture of trace data. Trace PIUs, which are not relevant to accounting, are discarded unless the STRACE command is issued.
NTS can only collect accounting data for selected sessions, or globally for all sessions, depending on the value of the SYSPARMS NTSACCT operand.
When selective accounting (the default) is specified, accounting data is collected for those sessions that match SAW classes requiring the collection of accounting data.
A specific trace request is issued by NTS to the session partner that resides in the VTAM subarea (or to the primary partner, if both session partners reside in the local subarea). This is because VTAM captures trace data only when the session traffic transits the VTAM host. In other words, unless one session partner resides in the VTAM subarea, no trace data is captured by VTAM.
Collection From Another VTAM Domain
The NTS Single Image (NTS-SI) feature does, however, allow you to access data from domains other than the domain in which your NTS region is active. Provided that the NTS systems are linked by suitably configured ISR links, NTS-SI lets you access trace data from other NTS systems in other domains exactly as if the session partners were both in the local domain.
Capturing Trace Data
In the following illustration, VTAM A is aware that there is an existing session between terminal D and CICS. However, because this session does not transit VTAM A, trace data is not delivered directly to NTS A. Trace data for this session is received from NTS B, due to the existence of a suitably configured ISR link.
Note the following in this illustration:
When global accounting is specified, NTS starts all global tracing options, to capture trace data for every available session. In this case, the starting and stopping of trace data collection by means of the STRACE command does not affect data capture, but whether trace PIUs are retained or not.
NTS attempts the collection of RTM data for LU-LU sessions that are matched with an RTM class only. Additionally, the following must apply:
When the session start notification is received for such sessions, the RTM class values are extracted by NTS and stored with the session record. At the same time, a request is sent to the terminal control unit to set the RTM boundary and definition parameters for the device according to these RTM class values. If the PU indicates it does not support the RTM function, or does not support host programming, then no further requests are sent to the control unit.
When a session for which RTM data is being collected ends, the RTM data collected by the secondary device is sent unsolicited to NTS and stored with other session information.
RTM data can also be solicited during NTS review functions or more systematically, through the standard NEWS RTM procedures that allow collection on a timer or interval basis (see the User Guide). Whenever RTM data is solicited by any means, NTS updates its statistics for the session.
As RTM data arrives, it is first examined by NTS to determine whether or not the performance objectives defined for the RTM class have been met. If not, this information is appended to the CNM record and made available to NEWS. This can lead to generation of performance events and, ultimately, attention messages to notify network operators of a performance problem.
When a session for which RTM data is being collected ends, a performance event notification is also generated by NTS if the response time objectives are not met.
One of the primary functions of NTS is to gather data from a number of sources and correlate it at session level. To protect NTS from waiting indefinitely for session data, you define an interval that represents the time limit for data correlation.
The NTS correlation interval is enforced in the following situations: