Recovery during restart

When a CICS region starts up after a previous shutdown, the CICS region performs recovery processing to return the region to the same state that it was in when it was last shut down. The CICS region automatically decides whether to perform a warm start (following a normal shutdown) or an emergency restart (following a system failure). You can force a cold start (in which the system log is reset during initialization), but data integrity problems can occur; for example, from in-doubt transactions that are not being recovered.

During a restart, the system data that was loaded into operating system memory during the previous run is used. For example, the resources that are in the autostart database are used (and not reloaded from the permanent database).

Recovering the state of recoverable resources after a system failure requires an external record of all the work that needs to be redone. For this purpose, CICS® is configured to take checkpoints periodically of the states of all recoverable resources. On restart, CICS reads the checkpoint to reestablish the states of the recoverable resources at the time the checkpoint was written, then processes all relevant information that is held for the region. You can control the frequency with which checkpoints are taken.

The emergency restart procedure is as follows:
  1. The CICS region opens the main system log and creates a list of application servers whose individual logs indicate in-doubt transactions.
  2. If application servers have been terminated cleanly, the CICS region starts them normally. For those application servers with in-doubt transactions, the CICS region starts the servers in recovery mode and waits for them to read their logs.
  3. Each application server with in-doubt transactions opens and reads its log to determine what recovery is needed, as follows:
    • It does not recover transactions that were active but not in doubt.
    • For transactions that were in doubt, the action depends on the transaction's state:
      • If the transaction is prepared and committed, the application server waits for "finished" responses from its subordinate transactions. These responses are received and logged.
      • If the transaction is prepared, the application server waits for an outcome from the coordinator of the transaction. When the outcome arrives, the outcome action is taken. When X/Open XA-compliant databases are in use, the outcome is also passed to the database by using the XA protocol.
After the application server has resolved its transactions, it continues to function normally.