To find out which tasks are associated with the error,
you can use the kernel task summary. The kernel task summary shows
which tasks were in the system when the dump was taken, whether those
tasks were running, and whether they were in error.
About this task
The task summary is in the form of a table, where each line in the table represents a different task. The left-hand column of the task summary shows the kernel task number, which is the number used by the kernel domain to identify the task. This is not the same as the normal CICS® task number taken from field TCAKCTTA of the TCA.
Figure 1 shows an example of a kernel task
summary with a task in error. Figure 1. Kernel task summary showing a task in error
Locate the task summary table in the formatted dump, and
look in the ERROR column. If you find a value of *YES* for
a specific task, that task was in error at the time that the dump
was taken.
Note: If the recovery routine that is invoked
when the error occurs does not request a system dump, you will not
see any tasks flagged in error. In such a case, the system dump is
likely to have been requested by a program that is being executed
lower down the linkage stack and that received an abnormal response
following recovery. The program that received the error has gone from
the stack, and so cannot be flagged. However, error data for the failing
task was captured in the kernel domain error table (see Finding more information about the error). Error data is also captured
in the error table even when no system dump is taken at all.
In Figure 1, you
can see that kernel task number 0090 is shown to be in error.
Look next at the STATUS column.
For each task you can see one of the following values:
***Running**, meaning that the task was running
when the system dump was taken. If more than one task is shown to
be running, the different tasks are attached to separate TCBs.
Not Running, meaning that the task is in the
system but is currently not running. For example, the task might be
suspended because it is waiting for a resource, or the task might
be ready to run but waiting for a TCB to become available.
KE_KTCB, referring to CICS control blocks that correspond to the CICS TCBs. These are treated as tasks in the kernel task summary.
Unused, meaning either that the task was in the
system but it has now terminated, or that there has not yet been a
task in the system with the corresponding task number. Earlier unused
tasks are likely to have run and terminated, and later ones are likely
never to have represented actual tasks. It is most unlikely that
you will ever need to distinguish between the two possibilities.
It is very likely that the task shown to be
in error has a status of Running, as in the example of Figure 1. Such a task would have been running
at the time the error was detected.
It is possible, but less likely,
that the task shown to be in error has a status of Not Running.
This situation might occur if the task in error was attempting recovery
when, for some reason, it was suspended.
If you are using trace to help you diagnose a problem,
use the TRAN_# and KE_NUM columns of the kernel task summary to find
more information about the task.
The TRAN_# column for
a task can contain the following information:
A number that matches the task number in the corresponding trace
TCP for the CICS terminal control task
Other character entries for CICS system tasks (for example, a component identifier such as AP for a CICS system task in the AP domain).
When you are working with trace output, you can use the number from the TRAN_# column to identify entries associated with a user task up to the point when that task passes control to CICS.
To identify the CICS processing associated with the user task, use the entry in the KE_NUM column of the kernel task summary. This matches the KE_NUM shown in the full trace entries for the task so that you can distinguish the CICS processing associated with the task you are interested in from other CICS processing.