The transaction restart user-replaceable program (DFHREST) enables you
to participate in the decision as to whether a transaction should be restarted
or not.
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 CICS Recovery and Restart Guide.
Notes:
- 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 abended in the second or subsequent UOW, and
DFHREST requested a restart.
- Statistics on the total number of restarts against each transaction are
kept.
- Emergency restart does not restart any tasks.
- 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:
- A transaction in which the first and subsequent units of work change different
resources
- 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 the above conditions are not satisfied, CICS does not invoke the transaction restart
program and the transaction is not restarted.
[[ Contents Previous Page | Next Page Index ]]