To provide recovery, CICS must perform several functions. It must keep track of changes made to recoverable resources by tasks initiated using recoverable transactions. If a task failure occurs, CICS must trap the error condition so that it can give control to its recovery modules. If CICS didn't trap errors, the OS will abnormally terminate CICS. When recovery processing is required, CICS will backout any changes made as part of an incomplete LUW.

Recovery can be performed at the task level or at the system level. Task-level recovery is provided for any recoverable task that terminates abnormally. Recovery at the system level is provided for all tasks— often referred as in-flight-tasks—executing at the time of a CICS system failure.

We will concentrate on the task-level recovery, since that is your primary concern as application programmers. Keep in mind that the technique we will be using for task-level recovery will also help if the entire system should fail.


Recovery information is collected by the CICS logging facility. Logging is performed for individual tasks and for the entire system. Task-related recovery information is stored in a log known as the dynamic log. A unique dynamic log is maintained in virtual storage, for each task associated with a recoverable transaction. If the dynamic log becomes too large, temporary storage is used to store the additional information. The dynamic log for a task is cleared at the beginning of each LUW. At the end of the task, its processing is considered committed and the dynamic log for the task is released.

The dynamic log is used to save information about all changes made by the current LUW for the task. This includes changes to recoverable files including before-images of updated or deleted records and keys of new records added to the file, the first VTAM input message for a message protected task, for restartable transactions, the contents of the TIOA, the TCT user area and the communications area passed to the task. Information needed to recover TSQ and Intrapartitioned TDQs is kept in the TST and DCT entry for each queue as well as in the queues themselves.

Information saved in a task's dynamic log is also permanently saved in the system log. The system log is a CICS journal file used during emergency restart to provide recovery for in-flight-tasks. In addition to the information found in all dynamic log areas, the system log also contains information normally found in virtual storage during the task's recovery. System log also contains information needed to restart the system, including the task sync point information and system activity key points, snap shots of the key system tables, etc.

Dynamic Transaction Backout

The process of backing out changes made to recoverable resources is known as Dynamic Transaction Backout (DTB). When a task failure occurs, the CICS Dynamic Transaction Backout Program (DBP) backs out the changes that are recorded in the dynamic log of the abending task. Because a new dynamic log is created for each LUW, the result of DTB is to restore recoverable resources to their state before the LUW began. DBP performs the following functions:

  • CICS files and DL/I databases are restored to their pre-LUW state. Records that were updated will be replaced with their before-images found in the dynamic log. Deleted records will be added back. Added records will be deleted.
  • Intrapartition TDQs and TSQs will be restored to their pre-LUW stated
  • Interval control START requests for which PROTECT has been specified will be cancelled. The data passed by the start request will be removed from the TSQ if the TSQ is defined as recoverable.

DTB will perform a significant amount of processing, depending on the number of recoverable resources used by the application program.

Automatic Transaction Restart (ATR)

Another recovery option that can be specified for a transaction is to restart the task automatically after abnormal termination. If restart is specified for the transaction, it will be attempted after DTB for the abending task is complete. Automatic transaction restart can be provided for transactions that access DL/1 databases and may be subject to program isolation deadlock.

For any other situations requiring automatic restart, modifications must be made to the Transaction Restart Program (RTY), which determines whether a transaction should be restarted. This program is defined as a user exit program of DTB. RTY returns a restart indicator to DTB, which will restart the transaction or continue with the abnormal termination.

When a task is restarted, it resumes execution as if the transaction were being executed for the first time, not at the beginning of the LUW that was backed out. This can make restart inappropriate for transactions with multiple LUWs. You must also check for recursive restarts in the RTY program before restarting a task, since CICS does not prevent this.

Automatic Journaling

User journals and autojournals are written to a general log stream defined to the MVS system logger.

  • User journaling is entirely under your application programs’ control. You write records for your own purpose using EXEC CICS WRITE JOURNALNAME commands. Automatic journaling means that CICS automatically writes records to a log stream, referenced by the journal name specified in a journal model definition, as a result of:
    1. Records read from or written to files. These records represent data that has been read, or data that has been read for update, or data that has been written, or records to indicate the completion of a write, and so on, depending on what types of request you selected for autojournaling.
  • You specify that you want autojournaling for VSAM files using the autojournaling options on the file resource definition in the CSD. For BDAM files, you specify the options on a file entry in the file control table.
    1. Input or output messages from terminals accessed through VTAM®.
  • You specify that you want terminal control autojournaling on the JOURNAL option of the profile resource definition referenced by your transaction definitions. These messages could be used to create audit trails.
  • Automatic journaling is used for user-defined purposes; for example, for an audit trail. Automatic journaling is not used for CICS recovery purposes

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

IBM Mainframe Topics