6. DATA SOURCES › 6.2 Processing Network Monitor Data From VM Hosts › 6.2.3 Tivoli NetView › 6.2.3.1 Tivoli NetView Session Monitor/NLDM

6.2.3.1 Tivoli NetView Session Monitor/NLDM

Tivoli NetView Session Monitor, formerly known as the Network
Logical Data Manager (NLDM) product, is an operational
performance tool used to monitor and manage day-to-day
network operations.  One of NetView's functions is to
collect, display, and record session response time data by
requesting and accepting response time data from the Response
Time Monitor (RTM), which is a microcode function provided in
the 3174 and 3274 cluster controllers.  NetView records the
response time data in the NetView external log record, which
may be written to SMF as the type 39 subtypes 1, 2, 4, and 5
records.  The NetView Session Monitor/NLDM also records
session configuration, the data traffic, connect, and VTAM
BIND failure information in the SMF type 39 subtypes 2, 3, 4,
5, and 6 records.  This information is referred to as NetView
accounting and availability data.  The CA MICS Network
Analyzer Option processes the SMF type 39 subtypes 1 through
6 record to add RTM and accounting and availability data to
the product database.

The INPUTSMF DD statement specifies the data set name for the
NetView Session Monitor/NLDM Files. It is your responsibility
to provide an archive file that contains the SMF type 39
records for daily processing by the CA MICS Network Analyzer
Option.

RESPONSE TIME MONITOR

The RTM function is provided in the 3274 and 3174 cluster
controllers.  This function includes a specific microcode
support level and a hardware timer adapter card that is read
by the microcode.  NetView/RTM data includes average response
time, a count of the responses that occurred within
user-defined response distribution times, and an indicator of
whether site-defined service objectives were met during the
data recording interval.

Since service objectives may be defined differently for
different network users, NetView/RTM permits the data center
to define performance classes and to associate each response
objective with a specific performance class.  A performance
class can be anything the data center defines, from a group
of sessions attached to a particular cluster controller to
all TSO sessions.  Performance classes are established using
the NetView PCLASS and MAPSESS definition statements.

When the NetView/RTM function is activated, the SMF type 39
record will be written at user-defined intervals and at
session termination.  The NetView COLLECT command is used to
produce type 39 subtype 1 records on an interval basis.  To
implement this feature, the data center must build and invoke
an NCCF CLIST to issue the COLLECT command at periodic
intervals.

NetView/RTM data is produced only for cluster controllers
with the microcode update and for sessions specifically
requested through the PCLASS and MAPSESS definition
statements.  In addition, interval records are produced only
when the COLLECT command is issued or when it is invoked
periodically by an NCCF CLIST.


ACCOUNTING AND AVAILABILITY

NetView accounting and availability (A/A) measurement data
consists of statistical data about user sessions, including
connect time, message and data traffic counts, configuration
data, and BIND failure information.

When the NetView A/A function is activated, the SMF type 39
record is written at session start, at session end, at user-
defined intervals, and when a session is rejected due to a
BIND failure.  The NetView RECORD command is used to produce
type 39 subtype 5 A/A records on an interval basis.  To
implement this feature, the data center must build and
invoke an NCCF CLIST, which issues the RECORD command at
periodic intervals.

Note that the NetView COLLECT command, which requests the
production of SMF type 39 subtype 1 records containing RTM
data, and the NetView RECORD command, which requests the
production of SMF type 39 subtype 5 records containing A/A
data, are not automatically synchronized.  Thus, the data
recorded for each function may represent information from
different time periods.  If you want to compare RTM and A/A
data for a given user session, you must ensure that the
COLLECT and RECORD commands are invoked together.  This does
not completely ensure that data from each source is for the
same time period, but it is the surest way to attempt such
correlation of data.  (RTM and A/A data are both included in
the session termination record, assuming they are both being
collected.)

See Section 6.3.9, Important Usage Notes for the NLL and LSY
Files, for a more complete discussion of this issue and its
effect on data in the CA MICS database.