Writing a transaction restart program

You can write a transaction restart user-replaceable program (DFHREST) to participate in the decision as to whether a transaction is restarted.

CICS® invokes DFHREST when a transaction abends, if RESTART(YES) is specified in the transaction's resource definition (the default is RESTART(NO)).

The default program requests restart under certain conditions; for example, in the event of a program isolation deadlock (that is, when two tasks each wait for the other to release a particular DL/I database segment or file record), one of the tasks is backed out and automatically restarted, and the other is allowed to complete its update.

For general information about restarting transactions, see the Troubleshooting for recovery processing.
Note:
  1. If your transaction restart program chooses to restart a transaction, a new task is attached that invokes the initial program of the transaction. This is true even if the task abends in the second or subsequent UOW, and DFHREST requested a restart.
  2. Statistics on the total number of restarts against each transaction are kept.
  3. Emergency restart does not restart any tasks.
  4. In some cases, the benefits of transaction restart can be obtained instead by using the SYNCPOINT ROLLBACK command. Although use of the ROLLBACK command is not usually recommended, it does keep all the executable code in the application programs.
When planning to replace the default DFHREST, check to see if the logic of any of your transactions is inappropriate for restart.
  • Transactions that execute as a single unit of work are safe. Those that execute a loop, and on each pass reading one record from a recoverable destination, updating other recoverable resources, and closing with a syncpoint, are also safe.
  • There are two types of transaction that need to be modified to avoid erroneously repeating work done in the units of work that precede an abend:
    1. A transaction in which the first and subsequent units of work change different resources
    2. A transaction where the contents of the input data area are used in several units of work.
  • Distributed transactions whose principal facilities are APPC links should not be considered for transaction restart. Restarting a back-end or front-end transaction while the other side of the conversation is still active presents problems with correct error handling and recovery of the conversation state.
All the following conditions must be true for CICS to invoke the transaction restart program:
  • A transaction must be terminating abnormally.
  • The transaction abend which caused the transaction to be terminating abnormally must have been detected before the commit point of the implicit syncpoint at the end of the transaction has been reached.
  • The transaction must be defined as restartable in its transaction definition.
  • The transaction must be related to a principal facility.

If these conditions are satisfied, CICS invokes the transaction restart program, which then decides whether or not to request that the transaction be restarted. CICS can subsequently override the decision (for example, if dynamic backout fails). Also, if the transaction restart program abends, the transaction is not restarted.

If these conditions are not satisfied, CICS does not invoke the transaction restart program and the transaction is not restarted.