Transaction abend processing

If, during transaction abend processing, another abend occurs and CICS® continues, there is a risk of a transaction abend loop and further processing of a resource that has lost integrity (because of uncompleted recovery). If CICS detects that this is the case, the CICS system abends with message DFHPC0402, DFHPC0405, DFHPC0408, or DFHPC0409.

How CICS handles transaction abends

The action taken by CICS on the abend exit code can:

Abnormal termination of a task describes the processing that may follow the abnormal termination of a task.

Exit code

Exit code can be written either in programs (separate modules defined in the CSD) or in routines within the application program. Exit code, if activated, can gain control when a task abend occurs.

Exit code can be activated, deactivated, or reactivated by HANDLE ABEND commands. For information about HANDLE ABEND commands, see the CICS Application Programming Reference.

Only one abend exit can be active at any given logical level 6 within a task. This means that:

  1. When one program LINKs to another program, the LINKed-from program and the LINKed-to program can each have one active exit.
  2. When an exit is activated (at a particular program level), any other exit that may already be active at the same level automatically becomes deactivated.

Reasons that an application programmer might have for coding a program level abend exit, and functions that might be incorporated, are discussed in Handling abends and program level abend exits.

When an abend request is issued for a task, CICS immediately passes control to the exit that is active at the current logical level:

When control is transferred to any exit code, CICS deactivates the exit before any of its code is executed. (This means that, in the event of another abend request, the exit will not be reentered, and control is passed to activated exit code (if any) at the next higher level.)

The exit code then executes as an extension of the abending task, and runs at the same level as the program that issued the HANDLE ABEND command that activated the exit.

After any program-level abend exit code has been executed, the next action depends on how the exit code ends:

Note:
If a transaction updates recoverable resources and, therefore, requires transaction backout to be performed in the event of a task abend, the exit code must end with an ABEND command to preserve data integrity. If your exit code simply returns to CICS without an ABEND command, CICS gives control to the next higher logical level as described above, transaction backout is not performed, and changes to recoverable resources are committed.

Abnormal termination of a task

If the exit code ends with an ABEND command, or if there is no active exit code, abnormal termination of a task starts after all active program-level abend exits (if any) have executed. The sequence of actions during abnormal termination of a task depends on the following factors:

Transaction restart

The transaction restart user-replaceable module (DFHREST) enables you to participate in the decision as to whether a transaction should be restarted or not. The default program requests restart under certain conditions; for example, in the event of a program isolation deadlock (for instance, when two tasks each wait for the other to release a particular DL/I database segment), one of the tasks is backed out and automatically restarted, and the other is allowed to complete its update.

For programming information about how to write your own code for DFHREST, see the CICS Customization Guide.

Notes:
  1. CICS invokes DFHREST only when RESTART(YES) is specified in a transaction’s resource definition.
  2. Ensure that resources used by restartable transactions, such as files, temporary storage, and intrapartition transient data queues, are defined as recoverable.
  3. When transaction restart occurs, a new task is attached that invokes the initial program of the transaction. This is true even if the task abended in the second or subsequent unit of work, and DFHREST requested a restart.
  4. CICS keeps statistics on the total number of restarts against each transaction.
  5. Emergency restart does not restart any user tasks that were in-flight when CICS abnormally terminated. Instead, recovery manager attaches a special task for each in-flight task that had recovery records in the system log at abnormal termination. This task invokes each resource manager to backout recoverable resources.
  6. Making a transaction restartable can involve slightly more overhead, because copies of the TCTUA, COMMAREA, and terminal input/output area (TIOA) have to be kept in case the transaction needs to be restarted. For more information about making transactions restartable, see the CICS Customization Guide.
  7. In some cases, the benefits of transaction restart can be obtained instead by using the SYNCPOINT ROLLBACK command. For more information about the use of the ROLLBACK option when working in an ISC or MRO environment, see the CICS Intercommunication Guide.
  8. A transaction initiated by terminal input is allowed to restart during shutdown, even if the transaction is defined as SHUTDOWN(DISABLED).

6.
Logical level. A LINKed-to program is said to be at a lower logical level than the program that issues the LINK command. The concept of logical levels is explained in the CICS Application Programming Guide.

[[ Contents Previous Page | Next Page Index ]]