2. USAGE CONSIDERATIONS › 2.5 Data Manipulation Guidelines

2.5 Data Manipulation Guidelines

This section describes different interpretations of the data
collected by Tivoli NPM, NetView Session Monitor/NLDM,
NetView Hardware Monitor/NPDA, CA NetMaster, and CA NetSpy
that may affect the usability of the data.

Tivoli NPM and CA NetSpy
------------------------

o   Comparison of application monitor (for example, CA
    TSO/MON PM), NPM, and CA NetSpy host response times.

    Tivoli NPM and CA NetSpy include VTAM processing time and
    operating system time as part of host response time.
    Application monitors start timing when they receive a
    request from VTAM and stop timing when they return the
    response to VTAM.  Therefore, host response time as
    measured by either NPM or CA NetSpy should be greater
    than that measured by an application monitor by the
    amount of VTAM processing time plus the operating system
    overhead incurred by VTAM.  In other words, VTAM delay
    can be approximated by subtracting the application
    monitor response time from the NPM or CA NetSpy response
    time for the same traffic.

o   Accuracy of response time measurements.

    Both Tivoli NPM and CA NetSpy assume that the time for a
    terminal to return a definite response approximates the
    time an input message takes to reach VTAM through the
    network.  Tivoli indicates that this is true for single
    request/response unit transactions only.  However, it
    seems reasonable that the complexity of the route and the
    rate of variance of overall network queuing delay will
    also affect the accuracy of this number.  In other words,
    the more network elements (links and nodes) through which
    a transaction passes, the more likely that the magnitude
    of the NPM or CA NetSpy response time error is increased.
    However, since this is just as likely to be
    underestimated as overestimated, analysis of a
    significant sample of data should closely approximate the
    actual response time.


NetView/NLDM CA NetMaster and the 3274/3174 Response Time
Monitor (RTM)
---------------------------------------------------------

o   Accuracy of response time measurements.

    Response time as measured by the 3274/3174 Response Time
    Monitor (RTM) in conjunction with either NetView Session
    Monitor/NLDM or CA NetMaster may be inaccurate in
    environments that use non-IBM hardware to link the
    terminal and the 3274 control unit.  For example,
    significant delay that is not measured by either NetView
    Session Monitor/NLDM or CA NetMaster could be imposed on
    an end-user if a local area network installation accesses
    a 3274 as a LAN gateway.  The RTM does not measure the
    time required to transfer data from the 3274/3174 control
    unit to the terminal.  A bottleneck in the 3274/3174 at
    this time can cause a significant delay.  Because the use
    of LANs is rapidly increasing, you should keep this
    potential source of error in mind.

o   Variation of response time measurements with response
    definitions.

    NetView Session Monitor/NLDM allows the data center to
    select the definition for the end of a transaction for
    the purpose of response timing.  This definition may be
    any of the following:

    o Receiving the first byte of the outgoing message
    o Receiving a keyboard unlock
    o Changing direction/ending bracket protocol
    o Time to last character

    Using the First Byte definition:

    This definition ignores the network transmission time for
    all but the first character of the message.  Frequently
    network transmission time represents the largest portion
    of response time.

    Using the Keyboard Unlock definition:

    If there are multiple outbound (transmission to terminal)
    messages for each transaction, all requesting definite
    response, this definition ignores the network response
    time for all messages after the first definite response.

NetView Hardware Monitor/NPDA and CA NetMaster NEWS
---------------------------------------------------

o   Cross-domain Recording Considerations

    Both NetView Hardware Monitor and CA NetMaster NEWS
    reliability data may be collected from multiple network
    domains and stored in the same network database.

    A single resource accessed by two separate domains (for
    example, network resources linked to both domains at
    different times) may have statistics, events, and alerts
    recorded under different symbolic names and identified as
    being attached to different higher-level resources.  You
    must take this into account when analyzing data in the
    SNTNEF and SNTNSF Files.