6. DATA SOURCES › 6.1 Data Sources Overview › 6.1.4 CA NetSpy › 6.1.4.8 CA NetSpy Data Considerations

6.1.4.8 CA NetSpy Data Considerations

CA NetSpy data will vary depending upon the environment in
which CA NetSpy operates and the CA NetSpy processing
options your CA NetSpy administrator chose.

The following sections discuss several CA NetSpy options and
the effect your CA NetSpy administrator's choices have on the
data in the CA MICS database. It also discusses a special CA
MICS Network Analyzer option that will eliminate the
inflation of character traffic and connect time in certain
multiple session manager environments.

Processing Subtype S and U Records
----------------------------------
Terminal statistics can be recorded in CA NetSpy record
subtypes S, T, and U.  Your CA NetSpy administrator controls
which records CA NetSpy produces by defining the CA NetSpy
initialization parameters in member INITPRM of the
partitioned data set CA NetSpy.CNTL.  Refer to Section 7.2.1
in this guide.

Target Specification
--------------------
In the CA NetSpy Application (APPL) statement in the INITPRM
member of CA NetSpy.CNTL, you can specify TARGET objective
values for response distributions.  Specification of TARGET
values results in CA NetSpy updating response distributions
that indicate how much response time deviates from the
average.

You can associate these TARGET values with either HOST
response time only or the combination of HOST and NETWORK
response time (TOTAL response time), based upon how you
specify the TARGETS in the INITPRM member of NETSPY.CNTL:

o If you specify TARGETS=HOST, the distribution counters are
  updated with HOST response time only.

o If you specify TARGETS=USER, the distribution counters are
  updated only when there is a network response that
  accompanies a host response.

Response Distributions and CA NetSpy Options
-----------------------------------------
CA NetSpy provides four response distribution targets that
you can associate with either host response time only, or
total response time (a combination of host and network
response).  If you specify the CA NetSpy parameter
TARGETS=HOST, then the response distribution fields will be
updated whenever a host response is complete, based on the
value of the host response time only.  If you specify the CA
NetSpy parameter TARGETS=USER, then the response distribution
fields will be updated based on combined host and network
response times.

Once CA NetSpy data is in the CA MICS SNTNSS and SNTNSP
files, you can determine which option was selected by
examining the common variable RDSTTYPE, which is set to HOST
or USER.  This will tell your CA MICS administrator whether
to associate the response distribution variables (NSSRDST1-5
or NSPRDST1-5) with NSSAVTTM (Average Total Response Time) or
NSSAVHTM (Average Host Response Time).

Calculating Total Response Time
-------------------------------
It is possible that not all response events have network
response time measured for them.  This will be true if the CA
NetSpy FORCEDR (force definite response) option associated
with the APPL parameter is valued at less than 100 (100
indicates that 100 percent of all transactions will have the
definite response option activated; 80 indicates that only 80
percent of the responses will have definite response
activated, etc.).  This will also be true if FORCEDR is not
used at all, and not all application transactions use
definite response.

CA MICS provides for this in its calculation of total
response time and average total response time.

Total network response time is calculated as follows:

o Average network response time is calculated as the network
  response time, measured by CA NetSpy, divided by the number
  of network response events.

o Then, the average network response time is multiplied by
  the total number of responses.  Total number of responses
  is set to the greater of network and host responses.  So,
  when there are fewer network responses, the CA MICS Network
  Analyzer Option simply obtains the average network response
  and calculates "approximation" of total token response.
  The measured network response time is kept in fields
  NSPNRSTM and NSSNRSTM.  The calculated value is maintained
  in fields NSPCNRTM and NSSCNRTM.

Total response time is calculated as the sum of host response
time and "calculated" network response time.  The average
total response time results from dividing total responses
into average total response time.

Multiple Session Manager Considerations
---------------------------------------
CA NetSpy provides a special interface to resolve the data
inflation problems present in a multiple session manager
environment.  This interface only resolves these problems 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 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 CA MICS.  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.  For example, suppose 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, has two simultaneous applications (TSO and CICS)
active through it, then there are three records in the SNTNSS
file for each interval of data.  If the real terminal name
(SLU) is T110215, 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 (47,255 characters).  Records 2 and 3 contain
character traffic information for all data transferred
between the terminal and each of those applications (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 can 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, can 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 on the network.