This section includes:
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:
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.
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.
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.
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 |
![]() ![]() |
![]() ![]() |
![]() ![]() |
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 |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
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.
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 =
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:
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).
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).
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).
Figure 9 shows the relationship between the syncpoint elapsed time (field 173) and the suspend time (field 14).
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:
During the life of a user task, CICS measures, calculates, and accumulates the storage occupancy at the following points:
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.
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).
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:.