Hardware monitors that reside in the terminal controller or on a network communications line cannot accurately differentiate between host and network response time. However, CA NetSpy is a software monitor that resides in the host; therefore, it can accurately differentiate between host response time and network response time.
Response time is measured as follows:
Note: The start of a transaction for a 3270-type terminal is defined as the time at which a user presses an attention identification (AID) key. The definition of the termination of a transaction can be tailored to specific applications by using the EOT parameter on the APPL statement in the initialization parameters file.
The response time the user perceives is the sum of A + B + C; however, because CA NetSpy resides entirely in the host, it only measures the times B, C, and D but not the time A. Instead of the time A, the time D is used as an approximation to A, and reports the sum B + C + D as the equivalent response time.
Various adjustments are made to D so that the approximation to A is as accurate as possible. For example, D is adjusted based on the size of the input transaction and the speed of the line. With this technique, you can approximate user-perceived response time.
Note: If the line speed at the NCP is set incorrectly or omitted, response time calculations will not be accurate. Line speed for each line is specified in the NCP source code through the SPEED parameter on a LINE statement (defining the speed to the NCP), or through the NPM.SPEED parameter on the line's LINE or GROUP statement (defining the speed to the CA NetSpy region). The value of NPM.SPEED overrides the value of the SPEED parameter.
Definite response is a VTAM function. It requests that the terminal send back a response to the application at the host indicating that the transaction has been processed (see the preceding diagram). Definite response is requested of the terminal during time C. If the terminal controller receives the completed transaction, it returns a positive response to the application (D).
For applications that do not use definite response, a feature lets you force a definite response, except for 4700 and 8100 type terminals, without the application's involvement. Because CA NetSpy can turn on definite response outside the application, it can measure network response times for these applications without contributing to application overhead. This is particularly important for CICS, since turning on definite response in CICS degrades CICS performance and user response time.
For terminals that do not allow a definite response to be forced, the total network response time is calculated based on the VTAM and NCP statistics.
Although an attempt is made to measure the network time for every transaction monitored, certain types of terminals cause this measurement to be unavailable or inaccurate. In these cases, CA NetSpy calculates the network response time. Examples include the following terminal types:
These terminals do not support the SNA definite response method. The network time, as measured by the round trip delay for the output to travel from the host to the terminal and an acknowledgment to return, does not include the polling delay. Therefore, CA NetSpy must calculate this delay to adjust its measured value for the network response time and obtain the true figure.
These terminals, mainly financial terminals like the 4700 and the 3600, do not return definite response immediately; therefore, this method cannot be used to measure the network response time. Instead, CA NetSpy must calculate the response time.
In these cases, the VTAM and NCP statistics are used for the reporting interval to calculate the different components of the network response time.
The NetSpy-to-NetSpy communication interface enables a CA NetSpy region not in session with an NCP to calculate response times when sessions exist among multiple CA NetSpy regions. One region must be in session with the NCP for this function to work.
You use the COLLECT POLLSTAT statement (in the STARTPRM file) to request the statistics necessary to calculate response times. These statistics are collected by the region in session with the NCP and sent to other regions. The region receiving this data then calculates response times.
Note: The NCP must be defined to all regions requesting the statistics and to the region in session with the NCP.
Because these calculations are based on mathematical formulas, they represent an average of the network time for the terminal during the reporting interval. There may not be an exact match for an individual transaction; therefore, these calculated network times cannot be used to populate the user-defined response time targets. Specifically, network and user targets are not available if the region cannot measure the network response time. For bisynchronous terminals, the network and user targets are populated with the unadjusted network times measured. As such, they do not reflect adjustment for bid-to-poll delay.
Network delays can be measured at the backbone level, which helps you determine exactly where a problem occurs. The backbone level of a network is the connection between network nodes. An example of a node is the NCP and the host.
The backbone network does not include the boundary lines, which connect each NCP with its cluster controllers and terminals.
To measure data at the backbone level, CA NetSpy monitors traffic on each virtual route (VR) that has its origin or destination subarea in a host where CA NetSpy is running.
The following diagram shows host and NCP subareas. The virtual route is the logical connection between subareas.
When you monitor the network at the backbone level, you can receive the collected statistics as real-time displays, online historical displays, or batch reports. In a large network with many subareas, the ability to measure network delays proves invaluable in pinpointing the cause of poor network response time.
Virtual route statistics include the following data:
The information in these reports helps you identify delays at specific locations in your network.
For LU 6.2 sessions, CA NetSpy maintains response time measurements and PIU counts.
In addition to measuring response times for LU 6.2 sessions that follow the normal "allocate (attach) and de-allocate" protocol, response times are reported for the following:
CA NetSpy automatically determines which method it uses to measure response time and reports this with an "LU62" or "RT62" flag in the displays and reports.
It measures and reports response times for LU 6.2 sessions that have PIUs following, both inbound and outbound. The host response time is the time spent in the application before allowing the session partner to respond. The network response time is the time spent outside the application waiting for the session partner to respond.
If a session has data flowing only in one direction, then no response times can be reported. Average and worst response times are kept at both the session and application level.
CA NetSpy counts the number of inbound and outbound PIU chains, and for those LU 6.2 sessions that send all the input or output as middle-in-chain, it counts the number of inbound and outbound PIUs. (Any input containing a request header or any output containing a request or response header is considered a PIU.)
Both statistics are reported as the number of inputs and outputs, respectively.