This section applies to threads that exploit CP parallelism or utility parallelism.
If a thread exploits parallelism, several tasks (called parallel tasks) are scheduled to perform the parallel work. For each of these tasks an Accounting record is generated, which contains counters and timers for the work performed by the particular task. In addition, the Accounting record for the thread contains the details about non-parallel work within the thread and also some parallel work-related data.
OMEGAMON® XE for DB2® PE summarizes all Accounting records generated for such a thread and presents them as one logical Accounting record. Table 1 describes which values are a combination of the originating task’s and parallel tasks’ values and which are taken from the originating task only.
To avoid incorrect time values, the data collector must be active with CCP=YES switched on if query parallelism or utility parallelism is used. In this case, the data collector can collect data of parallel tasks that have already terminated.
For Sysplex parallelism, thread activity information is only shown for the originating task and for those parallel tasks that are executing on the same member as the originating task. Parallel tasks that are executing on different members of the Sysplex group are ignored. Sysplex parallelism threads are marked by *S* next to the program name in the Thread Summary panel.
Especially interesting is the relationship between elapsed time, CPU time, and suspension times in the case of query parallelism or utility parallelism. The elapsed time is taken from the originating record while CPU and suspension times are calculated from all parallel and originating records. Consequently, both CPU time and suspension times can be larger than the elapsed time. Therefore, you can only get the full picture of the response time distribution if the times for each participating task are known. Produce a long Record trace for IFCID 3 using the Batch reporting facilities, especially if you suspect that the CPU times or suspension times for a thread where query parallelism or utility parallelism is used are large for other reasons than the times being added for several tasks. In a long Record trace, all Accounting records for parallel and originating threads are reported separately.
| Accounting Data | Derivation |
|---|---|
| Identifiers (PRIMAUTH, PLANNAME, and so on) | Originating task |
| Class 1 elapsed time | Originating task |
| Class 1 TCB times | Separate counters for originating task and sum of all parallel tasks |
| Class 2 elapsed time | Originating task |
| Class 2 TCB times | Separate counters for originating task and sum of all parallel tasks |
| Class 7 elapsed time | Originating task |
| Class 7 TCB times | Separate counters for originating task and sum of all parallel tasks |
| Class 2 and class 7 DB2 entry/exit events | Originating task |
| Class 3 and class 8 times | Separate counters for originating task and sum of all parallel tasks |
| Class 3 and class 8 events | Sum of originating task and all parallel tasks |
| Class 5 times | Originating task |
| SQL counters | Originating task |
| RID List counters | Sum of originating task and all parallel tasks |
| Query Parallelism counters | Originating task |
| Locking (including data-sharing-specific) counters | Sum of originating task and all parallel tasks |
| RLF data | Originating task |
| Buffer Pools counters | Sum of originating task and all parallel tasks |
| Group Buffer Pools counters | Sum of originating task and all parallel tasks |
| DDF counters | Originating task |
| Data Capture counters | Originating task |