Abnormal termination recovery

CICS® provides a program-level abend exit facility so that you can write your own exits (programs or routines) that can receive control during abnormal termination of a task. An example of a function performed by such an abend exit is the clean up of a program that has started but has not completed normally.

Some causes of abnormal terminations are as follows:
  • A user request, for example, by the following code: 
    EXEC CICS ABEND ABCODE(...)
  • A CICS request as a result of an invalid user request. For example, an invalid FREEMAIN request results in the transaction abend code ASCF.
  • A program check. The system recovery program (DFHSRP) is driven and the task abends with code ASRA.
  • An operating system abend. The DFHSRP program is driven and the task abends with code ASRB.
  • A looping task. The DFHSRP program is driven and the task abends with code AICA.
Note: If an ASRB or ASRA is detected in CICS code, CICS produces a dump before calling your HANDLE ABEND exit.

See Troubleshooting and support for full details about fixing problems. See CICS messages for information about the transaction abend codes for abnormal terminations that are initiated by CICS, their meanings, and your responses.

The HANDLE ABEND command activates or reactivates a program-level abend exit in your application program; you can also use this command to cancel a previously activated exit.

When activating an exit, you must do one of the following:
  • Use the PROGRAM option to specify the name of a program to receive control.
  • For COBOL or assembler applications only (but not AMODE(64) assembler applications), use the LABEL option to specify a routine label to which control branches when an abnormal termination condition occurs.

    You cannot use the HANDLE ABEND LABEL command with C, C++, PL/I or AMODE(64) applications. In PL/I, the equivalent is using an ON ERROR block.

A HANDLE ABEND command overrides any preceding such command in any application program at the same logical level. Each application program of a transaction can have its own abend exit, but only one abend exit at each logical level can be active. (Logical levels are explained in Program control.)

When a task terminates abnormally, CICS searches for an active abend exit, starting at the logical level of the application program in which the abend occurred, and proceeding to successively higher levels. The first active abend exit found, if any, is given control. This procedure is shown in Figure 1, which also shows how subsequent abend processing is determined by the user-written abend exit.

If CICS finds no abend exit, it passes control to the abnormal condition program to terminate the task abnormally. This program invokes the user replaceable program error program, DFHPEP. For programming information about how to customize DFHPEP, see Writing a program error program.

CICS deactivates the exit upon entry to the exit routine or program to prevent recursive abends in an abend exit. If you want to try the operation again, you can branch to a point in the program that was in control at the time of the abend and issue a HANDLE ABEND RESET command to reactivate the abend exit. You can also use this command to reactivate an abend exit (at the logical level of the issuing program) that was canceled previously by a HANDLE ABEND CANCEL command. You can suspend the HANDLE ABEND command with the PUSH HANDLE and POP HANDLE commands, as described in Using PUSH HANDLE and POP HANDLE commands.

When an abend is handled, the dynamic transaction backout program is not invoked. If you need the dynamic transaction backout program, you take an implicit or explicit sync point, or issue SYNCPOINT ROLLBACK, or issue an ABEND command.

Where the abend is the result of a failure in a transaction running in an IRC-connected system, for example AZI2, the sync point processing can abend ASP1 if it attempts to use the same IRC connection during its backout processing.

The HANDLE ABEND command cannot intercept ASPx or APSJ abend codes.