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:
v If the exit code ends with an ABEND command, CICS gives control to the next
higher level exit code that is active. If no exit code is active at higher logical
levels, CICS terminates the task abnormally. The next topic describes what may
happen after abnormal termination of a task.
v If the exit code ends with a RETURN command, CICS returns control to the next
higher logical level at the point following the LINK command (not to any exit
code that may be active) just as if the RETURN had been issued by the lower
level application program. This leaves the task in a normal processing state, and
it does not terminate at this point.
In the special case of a RETURN command being issued by exit code at the
highest logical level, CICS regains control and terminates the task normally. This
means that:
1. Dynamic transaction backout is not performed.
2. An end-of-task syncpoint record is written to the system log.
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
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:
v Code in the transaction restart program (DFHREST)
v Whether the transaction has freed the principal facility
v Whether backout was successful
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.
Note:
Chapter 8. Unit of work recovery and abend processing 93