Notes on the performance data

This section includes:

Transaction timing fields

Product-sensitive programming interface

The CMF performance class record provides detailed timing information for each transaction as it is processed by CICS®. A transaction can be represented by one or more performance class records depending on the monitoring options selected. The key transaction timing data fields are:

The CMF performance class record also provides a more detailed breakdown of the transaction suspend (wait) time into separate data fields. These include:

End of Product-sensitive programming interface

Response time

Product-sensitive programming interface

You can calculate the internal CICS response time by subtracting performance data field 005 (start time) from performance data field 006 (stop time).

Figure 5 shows the relationship of dispatch time, suspend time, and CPU time with the response time.

Figure 5. Response time relationships
 The response time is the total time from the transaction start time, to the transaction stop time. The response time can be subdivided into two periods, the suspend time and the dispatch time. The suspend time includes the first dispatch delay, which begins at the transaction start time and ends partway into the suspend time. The suspend time also includes the dispatch wait, which begins further on into the suspend time, and ends when the suspend time ends and the dispatch time begins. The dispatch time includes the CPU time, which begins some time after the start of the dispatch time, and ends some time before the dispatch time ends.
End of Product-sensitive programming interface
Start of change

Transaction dispatch time and CPU time

The transaction total dispatch time field USRDISPT, field 007 in group DFHTASK, is the total elapsed time during which the user task was dispatched by the CICS dispatcher domain on each CICS TCB under which the task executed.

The transaction total CPU time field USRCPUT, field 008 in group DFHTASK, is the total processor time during which the user task was dispatched by the CICS dispatcher domain on each CICS TCB under which the task executed.

For both these fields, the time recorded in the field can be associated with any of the TCB modes which are managed by the CICS dispatcher in the current CICS release. These include open TCBs, such as L8 mode TCBs, as well as non-open TCBs, such as the QR TCB. Be aware that for each CICS release, new TCB modes might be added or obsolete TCB modes might be removed, particularly in the case of the open TCB modes. You should always check the performance data field descriptions in the current release documentation to see which TCB modes are applicable. The field descriptions are listed in Performance data in group DFHTASK.

If you want to calculate a transaction's ratio of accumulated CPU time to accumulated dispatch time (CPU/DISP ratio) for the QR TCB, use fields 255 (QRDISPT) and 256 (QRCPUT) in group DFHTASK. These fields show the elapsed time and processor time during which the user task was dispatched on the QR TCB only.

The CPU/DISP ratio for an individual task should always be considered in the context of other activity in the CICS region. The Dispatcher TCB Modes report (see Dispatcher TCB Modes Report) which is provided by the sample statistics program DFH0STAT includes a calculation of the CPU/DISP ratio for the QR TCB for the whole CICS region.

End of change

Wait (suspend) times

Product-sensitive programming interface

The performance data fields listed in Table 4 all record the elapsed time spent waiting for a particular type of I/O operation. For example, field 009 records the elapsed time waiting for terminal I/O. The elapsed time includes not only that time during which the I/O operation is actually taking place, but also the time during which the access method is completing the outstanding event control block, and the time subsequent to that until the waiting CICS transaction is redispatched.

Table 4. Performance class wait (suspend) fields
Field-Id Group Name Description
009 DFHTERM TC I/O wait time
010 DFHJOUR JC I/O wait time
011 DFHTEMP TS I/O wait time
063 DFHFILE FC I/O wait time
100 DFHTERM IR I/O wait time
101 DFHDEST TD I/O wait time
123 DFHTASK Global ENQ delay time
128 DFHTASK Lock Manager delay time
129 DFHTASK Local ENQ delay time
133 DFHTERM TC I/O wait time - LU6.1
134 DFHTERM TC I/O wait time - LU6.2
156 DFHFEPI FEPI Suspend time
171 DFHTASK Resource manager interface (RMI) suspend time
174 DFHFILE RLS FC I/O wait time
176 DFHFILE Coupling Facility data tables server I/O wait time
177 DFHSYNC Coupling Facility data tables server syncpoint and resynchronization wait time
178 DFHTEMP Shared TS I/O wait time
181 DFHTASK EXEC CICS WAIT EXTERNAL wait time
182 DFHTASK EXEC CICS WAITCICS and WAIT EVENT wait time
183 DFHTASK Interval Control delay time
184 DFHTASK "Dispatchable Wait" wait time
186 DFHDATA IMS™ (DBCTL) wait time
187 DFHDATA DB2 ready queue wait time
188 DFHDATA DB2 connection time
189 DFHDATA DB2 wait time
191 DFHTASK RRMS/MVS wait time
192 DFHTASK Request Receiver wait time
193 DFHTASK Request Processor wait time
195 DFHTASK CICS BTS run process/activity synchronous wait time
196 DFHSYNC Syncpoint delay time
241 DFHSOCK Inbound Socket I/O wait time
Start of change247End of change Start of changeDFHTASKEnd of change Start of changeCICS change-TCB mode delay timeEnd of change
250 DFHTASK CICS MAXOPENTCBS delay time
254 DFHTASK Java™ Virtual Machine (JVM) suspend time
268 DFHTASK TCB mismatch wait time
277 DFHTASK CICS MAXJVMTCBS delay time
279 DFHTASK MVS storage constraint wait time
Start of change281End of change Start of changeDFHTASKEnd of change Start of changeCICS MAXSSLTCBS delay timeEnd of change
Start of change282End of change Start of changeDFHTASKEnd of change Start of changeCICS MAXXPTCBS delay timeEnd of change
285 DFHTASK 3270 bridge partner wait time
299 DFHSOCK Outbound Socket I/O wait time

Figure 6 shows an example of the relationship between a typical transaction wait time field, and the transaction's suspend time, dispatch time, CPU and dispatch wait time fields.

Figure 6. Wait (suspend) time relationships
 This transaction has a period of suspend time, which is the time between two periods of dispatch and CPU time. The period of suspend time is equal to the total of all the relevant wait times. The period of suspend time includes the dispatch wait, which ends when the suspend time ends and the dispatch and CPU time starts.

Improvements to the CMF suspend time and wait time measurements allow you to perform various calculations on the suspend time accurately. For example, the "Total I/O Wait Time" can be calculated as follows:

Total I/O wait time =

The "other wait time" (that is, uncaptured wait (suspend) time) can be calculated as follows:

Total other wait time =

Note:
The First Dispatch Delay performance class data field includes the MXT and TRANCLASS First Dispatch Delay fields.

The Uncaptured wait time can be calculated as follows:

Uncaptured wait time =

    (Suspend - (total I/O wait time + total other wait time))

In addition to the transaction "Suspend (wait) Time" breakdown, the CMF performance class data provides several other important transaction timing measurements. They include:

End of Product-sensitive programming interface

Program load time

Product-sensitive programming interface

Figure 7 shows the relationship between the program load time (field id 115) and the dispatch time and the suspend time (fields 7 and 14).

Figure 7. Program load time
 This diagram is based on the figure above, 'Response time relationships'. As in the previous figure, the transaction's response time is the total time from the transaction start time, to the transaction stop time. The response time can be subdivided into two periods, the suspend time and the dispatch time. The suspend time includes the first dispatch delay, which begins at the transaction start time and ends partway into the suspend time. The suspend time also includes the dispatch wait, which begins further on into the suspend time, and ends when the suspend time ends and the dispatch time begins. The dispatch time includes the CPU time, which begins some time after the start of the dispatch time, and ends some time before the dispatch time ends. In this version of the diagram, the dispatch time also includes the program load time. The program load time begins after the start of the dispatch time, and overlaps with the first part of the CPU time.
End of Product-sensitive programming interface

RMI elapsed and suspend time

Product-sensitive programming interface

The RMI elapsed time (group name: DFHTASK, field id: 170) and suspend time (group name: DFHTASK, field id: 171) fields provide an insight into the amount of time that a transaction spends in the CICS resource manager interface (RMI).

Figure 8 shows the relationship between the RMI elapsed time and the suspend time (fields 170 and 171).

Figure 8. RMI elapsed and suspend time
 The RMI elapsed time includes part of a period of dispatch and CPU time, at the start. This period of time began before the RMI elapsed time. When the dispatch and CPU time ends, the RMI suspend time then begins. The RMI suspend time includes a dispatch wait, at the end. When the dispatch wait ends, another period of dispatch and CPU time begins. Shortly afterward, the RMI elapsed time ends, while the dispatch and CPU time continues. The RMI elapsed time therefore includes parts of two periods of dispatch and CPU time, with an intervening period of RMI suspend time.
Note:
The DB2 wait, the DB2 connection wait, and the DB2 readyq wait time fields as well as the IMS wait time field are included in the RMI suspend time.
End of Product-sensitive programming interface

JVM elapsed time and suspend time

Product-sensitive programming interface

The JVM elapsed and suspend time fields provide an insight into the amount of time that a transaction spends in a Java Virtual Machine (JVM).

Care must be taken when using the JVM elapsed time (group name DFHTASK, field id: 253) and JVM suspend time (group name DFHTASK, field id: 254) fields in any calculation with other CMF timing fields. This is because of the likelihood of double accounting other CMF timing fields in the performance class record within the JVM time fields. For example, if a Java application program invoked by a transaction issues a read file (non-RLS) request using the Java API for CICS (JCICS) classes, the file I/O wait time will be included in both the file I/O wait time field (group name DFHFILE, field id: 063), and the transaction suspend time field (group name DFHTASK, field id: 014), as well as the JVM suspend time field.

The JVM elapsed and suspend time fields are best evaluated from the overall transaction performance view and their relationship with the transaction response time, transaction dispatch time, and transaction suspend time. The performance class data also includes the amount of processor (CPU) time that a transaction used whilst in a JVM. When a transaction uses a JVM in CICS key, which runs on a CICS J8 mode TCB, the processor time is recorded in the J8CPUT field (group name: DFHTASK, field id: 260). When a transaction uses a JVM in user key, which runs on a CICS J9 mode TCB, the processor time is recorded in the J9CPUT field (group name: DFHTASK, field id: 267).

Note:
The number of Java API for CICS (JCICS) requests issued by the user task is included in the CICS OO foundation class request count field (group name: DFHCICS, field id: 025).
End of Product-sensitive programming interface

Syncpoint elapsed time

Product-sensitive programming interface

Figure 9 shows the relationship between the syncpoint elapsed time (field 173) and the suspend time (field 14).

Figure 9. Syncpoint elapsed time
 The syncpoint elapsed time includes several periods of time. It begins during a period of dispatch and CPU time. A period of suspend time follows, which includes a dispatch wait at the end. When the dispatch wait and the suspend time end, there is another period of dispatch and CPU time. When this period ends, another period of suspend time begins, which includes another dispatch wait. When the dispatch wait and the suspend time end, another period of dispatch and CPU time begins. Shortly afterward, the syncpoint elapsed time ends, while the period of dispatch and CPU time carries on. The syncpoint elapsed time in this example therefore includes two complete periods of suspend time.
End of Product-sensitive programming interface

Storage occupancy counts

Product-sensitive programming interface

An occupancy count measures the area under the curve of user-task storage in use against elapsed time. The unit of measure is the "byte-unit", where the "unit" is equal to 1024 microseconds, or 1.024 milliseconds. Where ms is milliseconds, a user task occupying, for example, 256 bytes for 125 milliseconds, is measured as follows:

   125  / 1.024 ms = 122 units  * 256 = 31 232 byte-units.

Note:
All references to "Start time" and "Stop time" in the calculations below refer to the middle 4 bytes of each 8 byte start/stop time field. Bit Start of change47End of change of Start time or Stop time represents a unit of 16 microseconds.

To calculate response time and convert into microsecond units:
      Response = ((Stop time - Start time) * 16)
To calculate number of 1024 microsecond "units":
      Units = (Response / 1024)
         or
      Units = ((Stop time - Start time) / 64)
To calculate the average user-task storage used from the storage
occupancy count:

      Average user-task storage used = (Storage Occupancy / Units)

To calculate units per second:
     Units Per Second = (1 000 000 / 1024) = 976.5625
To calculate the response time in seconds:
     Response time = (((Stop time - Start time) * 16) / 1 000 000)

During the life of a user task, CICS measures, calculates, and accumulates the storage occupancy at the following points:

Figure 10. Storage occupancy
 Over the response time of this transaction (the period from the transaction start time to the transaction stop time), the storage occupancy varies when a GETMAIN or FREEMAIN occurs. Storage occupancy rises with a GETMAIN, and falls with a FREEMAIN. On a graph, the storage occupancy appears as a series of rising and falling steps, and an average storage occupancy can be calculated.
End of Product-sensitive programming interface

Program storage

Product-sensitive programming interface

The level of program storage currently in use is incremented at LOAD, LINK, and XCTL events by the size (in bytes) of the referenced program, and is decremented at RELEASE or RETURN events. On an XCTL event, the program storage currently in use is also decremented by the size of the program issuing the XCTL, because the program is no longer required.

Figure 11 shows the relationships between the "high-water mark" data fields that contain the maximum amounts of program storage in use by the user task.

Figure 11. Relationships between the "high-water mark" program storage data fields
 Field PCSTGHWM contains the high-water mark of program storage in all CICS DSAs. Field PC31AHWM is a subset of PCSTGHWM, containing the high-water mark of program storage above the 16MB line. PC31AHWM has further subsets, field PC31CHWM (the ECDSA high-water mark), field PC31SHWM (the ESDSA high-water mark), and field PC31RHWM (the ERDSA high-water mark). Field PC24BHWM is the other subset of PCSTGHWM, containing the high-water mark of program storage below the 16MB line. PC24BHWM has further subsets, field PC24CHWM (the CDSA high-water mark), field PC24SHWM (the SDSA high-water mark), and field PC24RHWM (the RDSA high-water mark).

Field PCSTGHWM (field id 087) contains the maximum amount of program storage in use by the task both above and below the 16MB line. Fields PC31AHWM (139) and PC24BHWM (108) are subsets of PCSTGHWM, containing the maximum amounts in use above and below the 16MB line, respectively. Further subset-fields contain the maximum amounts of storage in use by the task in each of the CICS dynamic storage areas (DSAs).

Notes:
  1. The totaled values of all the subsets in a superset may not necessarily equate to the value of the superset; for example, the value of PC31AHWM plus the value of PC24BHWM may not equal the value of PCSTGHWM. This is because the peaks in the different types of program storage acquired by the user task do not necessarily occur simultaneously.
  2. If a task loads the same program several times, the program storage data fields might not reflect the true high-water mark of program storage used by the task. The fields are incremented each time the LOAD command is issued, but if the program has already been loaded by the task, the existing copy of the program is used, meaning that only one copy of the program actually exists in storage. Because of this, for tasks that repeatedly load the same program, the data in the fields PCSTGHWM, PC24BHWM, PC31RHWM, PC31AHWM, PC31CHWM, PC24CHWM, PC24SHWM, PC31SHWM and PC24RHWM should be used with caution.

The "high-water mark" fields are described in detail in User storage fields in group DFHSTOR:. For information about the program storage fields, see Program storage fields in group DFHSTOR:.

End of Product-sensitive programming interface

Related tasks
Controlling CICS monitoring
Processing CICS monitoring facility output

Related concepts
The CICS monitoring facility
The classes of monitoring data: Overview
Event monitoring points
The monitoring control table (MCT)

Related reference
Interpreting CICS monitoring
Performance class data
Exception class data
Transaction resource class data
[[ Contents Previous Page | Next Page Index ]]