CICS® recoverability options for local transactions are limited to:
- Automatic restart when a transaction abends
- Time-out when a transaction has been waiting for resources for longer
than a specified time interval, usually because the transaction is deadlocked
with another transaction for the same resources
- Allowing you to purge transactions that "hang" for reasons that
cannot otherwise be resolved
For remote transactions, in addition to the above, CICS provides in-doubt
options to specify the recovery action in the event of in-doubt failures.
When defining user transactions that update local resources,
you can specify the following options on the TRANSACTION resource definition
for recovery purposes:
- RESTART({NO|YES})
- This option defines whether, in some circumstances, the transaction
is eligible to be restarted automatically by CICS under the control of the DFHREST user
replaceable module.
The default is RESTART(NO).
- DTIMOUT({NO|1-6800})
- If the task remains suspended (inactive) for the specified interval
(and SPURGE(YES) is also specified), CICS initiates an abnormal termination of
the task. (Specifying SPURGE(NO) overrides the DTIMOUT option.)
The default
is DTIMOUT(NO).
- SPURGE({NO|YES})
- This option indicates whether the transaction is initially system-purgeable;
that is, whether CICS can purge the transaction as a result of:
- Expiry of a deadlock timeout (DTIMOUT) delay interval
- A CEMT, or EXEC CICS, SET TASK(id) PURGE|FORCEPURGE command.
The default is SPURGE(NO).
- TPURGE({NO|YES})
- This option indicates whether the transaction is system-purgeable in
the event of a (non-VTAM) terminal error.
The default is TPURGE(NO).
In-doubt options for distributed transactions
When defining user transactions that update remote resources,
you can specify the following options for remote recovery purposes (in addition
to the local options above):
- ACTION({BACKOUT|COMMIT})
- Specifies the action to be taken when a failure occurs during two-phase
commit processing, after the unit of work has entered the in-doubt period.
If
you’ve specified WAIT(YES), the action is not taken unless the interval
specified on WAITTIME expires before recovery occurs.
Whether you specify
BACKOUT or COMMIT is likely to depend on the kinds of changes made to resources
in the remote system.
- WAIT({YES|NO})
- Specifies whether a failed in-doubt unit of work is to wait, pending recovery
from the failure, to resolve its in-doubt state, or whether CICS is to take
immediately the action specified by the ACTION option.
Note:
A WAIT(YES)
option can be overridden by WAIT(NO) defined on an intrapartition transient
data queue. If a TD queue that is access by a transaction specifies WAIT(NO),
and the transaction specifies WAIT(YES), the TD queue definition forces the
transaction to either backout or commit, as specified by the ACTION attribute
on the transaction resource definition.
- WAITTIME({00,00,00|dd,hh,mm})
- Specifies, if WAIT(YES), how long the transaction is to wait before
taking the action specified by ACTION.
You can use WAIT and WAITTIME to
allow an opportunity for normal recovery and resynchronization to take place,
while ensuring that a transaction commits or backs out within a reasonable
time. See the CICS Intercommunication Guide for information
about defining wait times for distributed transactions.
For more information about recovery of distributed units of work, see the CICS Intercommunication Guide.
For more information about options on the TRANSACTION definition, see the CICS Resource Definition Guide.
[[ Contents Previous Page | Next Page Index ]]