Dumps for CICS DBCTL

The headings that follow describe dumps produced by CICS®, the DRA, and DBCTL.

CICS transaction dump

This dump is produced whenever a CICS task terminates abnormally. For a CICS-DBCTL task, that is, a task which has issued a DFHRMCAL request to DFHDBAT, this dump includes:

The recovery token for the task at the point of abnormal termination appears in the TCA (TCARTKN).

The EXEC CICS SET TRANDUMPCODE command and the CEMT SET TRANDUMPCODE transaction enable you to change some of the values recorded in entries in the transaction dump code table, to add new entries to the table, and to remove existing entries from the table. For example, you can specify an action for a particular CICS message, as mentioned in Figure 39.

For information about transaction dump codes, and interpreting CICS dumps, see the CICS Problem Determination Guide.

CICS system dump

This dump is produced when a CEMT PERFORM DUMP|SNAP or an EXEC CICS DUMP SYSTEM command is issued, or when CICS abends. CICS specifies all options when issuing this type of dump, for example, CSA and NUC. All MVS™ control blocks appear in this type of dump, including those corresponding to any subordinate TCBs. You can format and analyze this type of dump using the interactive problem control system (IPCS). For guidance on using IPCS, see the OS/390 MVS IPCS User’s Guide.

The EXEC CICS SET SYSDUMPCODE command and the CEMT SET SYSDUMPCODE transaction enable you to change some of the values recorded in entries in the transaction dump code table, to add new entries to the table, and to remove existing entries from the table. For example, you can specify an action for a particular CICS message, as mentioned in Figure 39.

For information about system dump codes, and interpreting CICS dumps, see the CICS Problem Determination Guide.

Determining whether a problem is occurring in CICS or DBCTL

To help you determine whether a problem is occurring in DBCTL or CICS, examine the CICS transaction or system dump. These dumps include indications of the point at which DFHDBAT passes control to DBCTL and the point at which DBCTL returns control to DFHDBAT. Correlating this with the time at which the problem occurred should tell you whether it was in CICS or DBCTL.

Each page of auxiliary trace output also includes a timestamp, as mentioned in Connection to DBCTL. These timestamps should also help you correlate events in CICS with events in DBCTL.

DRA snap data set

The DRA’s snap data set is dynamically allocated to the CICS address space when DBCTL is connected. The SYSOUT class used is determined by a parameter in the DRA startup table. The DRA dumps its control blocks (those associated with its own work unit and that of DBCTL) to this data set whenever a high order bit is set in PAPLRETC. (The participant adapter parameter list (PAPL) is a part of the DRA. For guidance on the PAPL and its contents, see the appropriate IMS Customization Guide.) The high order bit is set on if a thread is terminating. It then closes the snap file. The recovery token appears in the dump produced.

What is provided in a CICS dump

When a transaction abends or requests a dump, the following areas are written to the CICS dump data set(s):

Dumps produced by the DRA

DBCTL creates an SDUMP containing diagnostic information for a DL/I request failure from CICS using the system dump data sets from the CICS job.

The DRA produces an SDUMP in the following situations:

An SDUMP is created in a terminate address space request or a terminate thread request while running in DBCTL and under the DRA TCB.

An SDUMP contains:

If the SDUMP request fails, a SNAP dump (which contains a subset of the information in an SDUMP) is produced instead. (See Return codes in DBCTL.) The SNAP contains the following subset of the information produced in an SDUMP:

Because the DRA runs in problem state, it cannot access other storage areas, such as CSA or DBCTL storage. This may mean that the SNAP does not contain enough information, and you may have to recreate the failure and use the DBCTL address space dump.

See the IMS Diagnosis Guide and Reference manual manual for a further comparison of the information produced in SDUMPs and SNAP dumps, which you may find useful in diagnosis. The IMS Diagnosis Guide and Reference manual manual also contains information on the IMS™ offline dump formatter (ODF) which you can use to show the layout of IMS blocks referred to in these dumps.

Dumps produced by DBCTL

The formatted dump feature of IMS is available with DBCTL. This feature formats the system, database, and data communication areas of IMS. It formats the control blocks and data areas in an IMS region.

See the IMS Diagnosis Guide and Reference manual manual for guidance information on the areas that are dumped.

Control blocks generated by DBCTL have an "eyecatcher" for visual identification. For example:

The recovery token is included in dumps produced by DBCTL. Output is to the IMS log.

Related concepts
Problem determination for DBCTL
Interactions between CICS and DBCTL
DBCTL error scenarios
Trace for CICS DBCTL
Messages for CICS DBCTL
Using CICS EDF to debug application programs in DBCTL
[[ Contents Previous Page | Next Page Index ]]