The RESPONSETIME monitoring program records information on response times, think times, transactions times, and wait times in the BCAM pool. It supplies useful monitored data for dialog-oriented DCAM applications only (with NEA names).
The response time is understood to mean the time between the receipt of a message by the host and the sending of a response to the partner application.
SM2 makes a distinction between two kinds of response time:
Definition 1 | The time between an input (receipt of a message) and the next output (sending of a message) via the same connection. |
Definition 2 | The time between an input and the next output or all follow-up outputs sent before a further input. |
The SM2 administrator can choose between these two definitions (using the SET-RESPONSETIME-PARAMETERS or MODIFY-RESPONSETIME-PARAMETERS statement).
The think time is understood to mean the time taken between output and the next (subsequent) input. The transaction time is understood to mean the total time elapsed between an input and the final output. The wait time is understood to mean the time between entry of a message in the BCAM pool and retrieval of the message from this pool.
For simplicity, interaction is the term used as an overall definition covering the wait, response, think, transaction times.
Example: Calculating the time values
TI | Input time stamp | |
TO | Output time stamp | |
TR | Time stamp of the current receive action in the BCAM application | |
RT1 | = TO1-TI | Response time (definition 1) |
RT2 | = RT2, TO2-TO1, TO3-TO2, TO4-TO3 | Response time (definition 2) |
TrT | = TO4-TI | Transaction time |
ThT | = TI,next-TO4 | Think time |
WT | = TR-TI | Wait time |
The outputs at times TO1,2 cannot refer to the input at time T because the latter was not retrieved until time TR.
The outputs at times TO3,4 can (but need not) refer to the input at time TI.
Because the monitoring is performed in the BCAM transport system, no definite statement can be made about the logical (application-specific) connection between the individual inputs and outputs.
With dialog-oriented applications, each input is generally followed by the associated output, so the correct response times can be established.
SM2 interprets each message from a partner application to a BCAM application as an input and each message from a BCAM application to a partner application as an output. No distinction is made as to whether the communications partner of the BCAM application is a terminal or an application in a partner system.
In order to restrict monitoring to individual connections, SM2 employs the BCAM application name. SM2 assumes that the transmitter or receiver (terminal) has been uniquely assigned to a specific application name.
There are some special applications for which this application name has not been defined. Specific response time measurement by SM2 is not suitable for such cases, but the corresponding values are recorded in the total.
Wait times within the communications host and data transfer times cannot be taken into consideration.
Example: Responses to a /SHOW-FILE-ATTRIBUTES command
The SM2 administrator can use the SET- or MODIFY-RESPONSETIME-PARAMETERS statement and the ADD-CONNECTION-SET statement to define global and connectionspecific monitoring parameters respectively.
Global parameters
If response times are recorded for specific categories (SCOPE=*CATEGORY), the calculation of means values per category only involves values which are below the maximum corresponding bucket value. If no bucket-specific analysis is required, only one value is required to determine the overflow limit. If more than one bucket has been defined, values below this limit are ignored as being irrelevant, and the category assignment valid at the end of interaction remains applicable
Using the parameter CONNECTION-NUMBER=<integer 1..8187>, the maximum number of connections to be monitored is defined. Once this number is reached, response time monitoring continues, in which case SM2 will react to any unrecorded interaction in the following manner:
The message
NOTE: CONNECTION NUMBER TOO LOWwill be issued in the SM2 output report. Each of the RESPONSETIME screens (see description of the RESPONSETIME report) will show the same message. The message is output only if no interactions were recorded during the monitoring cycle in question.An indication to this effect will be given in the SM2 response record at the end of this monitoring cycle.
With SM2R1, the message SOME INTERACTIONS MISSED will be issued at the end of the analysis. This message is output only if no interactions were recorded during the analysis period in question.
The BUCKET parameters consists of a list of the maximum response, think, transaction and wait times, arranged in order of magnitude. The ranges defined in the specified lists apply to all connection sets specified in the ADD-CONNECTION-SET statement.
<integer 1 .. 99999> is an integer which defines the limit value. The number of limit values in this list implicitly determines the number of ranges. This may vary from list to list, but five limit values is the maximum. The last value in the list of ranges specifies the overflow limit. All monitored variables that exceed this limit value are included under the last value, but are not included in the calculation of mean values given in the RESPONSETIME report.
Connection-specific parameters
The SM2 administrator can monitor the response time both globally, i.e. for all possible connections, and for specific individual connections, connection groups, or connection sets.
A connection is uniquely defined in the local the host by specifying the following objects:
the name of an application
the name of a partner
the host name of the partner
the type of connection
A connection group is a number of connections that are defined by the specification of the application and of the type of the connection. The partner name and computer name of the partner cannot be specified. For example, ($DIALOG) defines a connection group which includes the $DIALOG application.
A connection set is understood as a combination of connection groups. It is defined by specifying a list of up to five connection groups.
For example, (($DIALOG),(UTM1)) defines a connection set which combines two connection groups with the $DIALOG and UTM1 applications.
This monitoring program supplies statistics for each connection set. In addition, the set of all connections is monitored on an ongoing basis. When selecting which connections are to be monitored, the SM2 administrator can define up to 15 connection sets. (*ALL) is always set automatically as the additional connection set. Furthermore, the SM2 administrator must specify whether the selected connections are to be monitored or excluded from monitoring using the *BY-CONNECTION or *EXCEPT-CONNECTION operand of the ADD-CONNECTION-SET statement. With *EXCEPT-CONNECTION, all connections except for those in the specified connection groups are monitored.
The SM2 administrator can also specify the type of the connection. If *LOCAL is specified, connections within the host are taken into account. This makes it possible to record the response times for individual applications, even if it would normally appear to the system that everything is running under the OMNIS carrier application.
Each defined connection set can consist of a maximum of five connection groups. The total number of connection groups which can be defined is, in turn, limited to 15 at most.
Examples of the RESPONSETIME monitoring program
Example 1
SET-RESPONSETIME-PARAMETER ADD-CONNECTION-SET SET-NAME=setname1,SET-DEFINITION=*BY-CONNECTION, CONNECTION-SET=((utm1),(utm2),(utm3)) ADD-CONNECTION-SET SET-NAME=setname2,SET-DEFINITION=*BY-CONNECTION, CONNECTION-SET=(utm3),CONNECTION-TYPE=*BOTH, ADD-CONNECTION-SET SET-NAME=setname3,SET-DEFINITION=*EXCEPT-CONNECTION, CONNECTION-SET=((utm1),(omnis),(apl1)) START-MEASUREMENT-PROGRAM TYPE=*RESPONSETIME
The above statements are used to explicitly define three connection sets: the first by specifying a list of three connection groups. These three connection groups are taken as a whole. The second connection set takes account of local and remote connections. All the other connection sets only take account of remote connections (corresponds to default setting). The third connection set combines all connections which belong to neither the UTM1 or OMNIS application nor to the explicit connection (apl1).
Example 2
REMOVE-CONNECTION-SET SET-NAME=*ALL MODIFY-RESPONSETIME-PARAMETERS DEFINITION=*2 ADD-CONNECTION-SET SET-NAME=setname,SET-DEFINITION=*EXCEPT-CONNECTION, CONNECTION-SET=($OMNIS) CHANGE-MEASUREMENT-PROGRAM TYPE=*RESPONSETIME
The above statements terminate the RESPONSETIME monitoring program (apart from *GLOBAL) and restart it, monitoring all connections with the exception of the $OMNIS application. In addition, the response time as defined in definition 2 is monitored. All other monitoring parameters from the response time monitoring process just terminated are retained.
Example 3
SET-RESPONSETIME-PARAMETERS CONNECTION-NUMBER=100,RESPONSETIME-BUCKETS= (50,100,200),THINKTIME-BUCKETS=(50,100,150,200,250) START-MEASUREMENT-PROGRAM TYPE=*RESPONSETIME
The SET-RESPONSETIME-PARAMETERS statement is used to automatically define a connection set with the name *GLOBAL; all connections in this set are monitored (CONNECTION(*ALL)). In addition, here the number of connections is limited to 100. Three limits (50, 100, 200) are set for the response time, and five limits (50, 100, 150, 200, 250) for the think time. The transaction time and the wait time in the BCAM pool are set to their default values.