6. DATA SOURCES › 6.3 Correlating Data Sources › 6.3.11 CA NetSpy Data Considerations › 6.3.11.1 Multiple Session Manager Considerations

6.3.11.1 Multiple Session Manager Considerations

Section 6.8, Multiple Session Manager Considerations,
describes the data effects when monitors such as NetView,
NPM, and CA NetSpy collect data on user sessions controlled
by a multiple session manager such as Tivoli NetView Access.
You should carefully review and understand Section 6.8 before
proceeding with the explanation below.

CA NetSpy provides a special interface to resolve the data
inflation problems present in a multiple session manager
environment.  This interface resolves these problems only for
the CA NetSpy VTAM Interface data (contained in the terminal
activity file and application activity file) and not for the
CA NetSpy network session accounting/network gateway
accounting data (contained in the NCP network accounting
file).  This interface is implemented through a handshake
between the multiple session manager and CA NetSpy whenever a
new application session is started or the user at a terminal
switches between applications.  The result is that the CA
NetSpy terminal record, which represents each virtual
terminal session between the multiple session manager and the
real application, contains valid network response times and
identifies, as the Secondary Logical Unit (SLU), the name of
the real terminal that initiated the session through the
multiple session manager.  CA NetSpy also identifies these
records as "virtual terminal" records with a flag.  In the CA
MICS SNTNSS file, a virtual terminal session is indicated
when variable NSSVSESS has a value of Y.

CA NetSpy also sets a "multiple session manager" flag in each
application record it produces for a multiple session
manager.  This flag is carried into the appropriate
application and terminal records by the CA MICS Network
Analyzer Option.  The PLUMSMGR flags in the SNTNSS and SNTNSP
Files are set to "Y" when the application (PLU) is recognized
by CA NetSpy as a multiple session manager.

These flags are useful when you want to summarize data in the
SNTNSS File by terminal.  Suppose, for example, you want to
know the total character traffic, NSSNRBYR plus NSSNRBYS, to
terminal T1102015.

The summarization sequence for the SNTNSS File results in an
observation for each application (PLU) and terminal (SLU).
In the case where a user is logged on to a multiple session
manager and has two simultaneous applications (TSO and CICS)
active through it, there are three records in the SNTNSS File
for each interval of data.  If the real terminal name (SLU)
is T1102015, then the records are:

Record 1 - SLU=T1102015, PLU= multiple session manager name
Record 2 - SLU=T1102015, PLU= TSO
Record 3 - SLU=T1102015, PLU= CICS

Record 1 contains character traffic information for all data
transferred between the real terminal and the multiple
session manager (for example, 47,225 characters).

Records 2 and 3 contain character traffic information for all
data transferred between the terminal and each of those
applications (for example, 21,225 characters for TSO and
24,100 characters for CICS).

Note that the session between the real terminal and the
multiple session manager recorded 1,900 more characters than
the total of the other sessions.  This is due to interaction
between the terminal user and the multiple session manager.

If you merely summarize the file by terminal name, you will
get a total character count of 92,550, approximately double
the real traffic to the terminal.  Instead, you may use
either the NSSVSESS or the PLUMSMGR flag to eliminate the
records with the redundant information.  If you want to
preserve the breakdown by application (TSO and CICS),
eliminate records with PLUMSMGR=Y.  If you are concerned
about accurate network traffic statistics, then eliminate
the records with NSSVSESS=Y.

An alternative to remembering to process this data as
described above is to use the SNTOPS parameter "DELETEMS YES"
to eliminate the records for the session between the multiple
session manager and the real terminal as the raw data is
being entered into the SNTNSS File.  When this parameter is
used, only the virtual terminal records will end up in the
SNTNSS File.  While this eliminates the possibility of
redundant data from improper summarization, it has these
drawbacks.

o Virtual terminal session data is missing the user's
  interaction with the multiple session manager.  It
  therefore may understate the volume of traffic to the
  terminal.

o Multiple session manager data compression features actually
  reduce the amount of data sent to the terminal.  Thus, the
  count of character traffic in the record that is dropped
  using "DELETEMS YES" may actually be less than that of the
  combined virtual terminal session records.  However, the
  count in the record dropped more accurately reflects the
  traffic in the network.