Filter
Top Products
Any non-RLS locks associated with in-flight (and other failed) transactions are
acquired as active locks for the tasks attached to perform the backouts. This means
that, if any new transaction attempts to access non-RLS data that is locked by a
backout task, it waits normally rather than receiving the LOCKED condition.
Retained RLS locks are held by SMSVSAM, and these do not change while backout
is being performed. Any new transactions that attempt to access RLS resources
locked by a backout task receive a LOCKED condition.
For both RLS and non-RLS resources, the backout of in-flight transactions after an
emergency restart is indistinguishable from dynamic transaction backout.
Effect of delayed recovery on PLTPI processing
Because recovery processing does not take place until PLTPI processing is
complete, PLT programs may fail during an emergency restart if they attempt to
access resources protected by retained locks. If PLT programs are not written to
handle the LOCKED exception condition they abend with an AEX8 abend code.
If successful completion of PLTPI processing is essential before your CICS
applications are allowed to start, consider alternative methods of completing
necessary PLT processing. You may have to allow emergency restart recovery
processing to finish, and then complete the failed PLTPI processing when the locks
have been released.
Other backout processing
The recovery manager also drives the backout processing for any units of work
that were in a backout-failed state at the time of a CICS failure and the commit
processing for any units of work that were in a commit-failed state at the time of a
CICS failure.
The recovery manager drives these backout and commit processes because the
condition that caused them to fail may be resolved by the time CICS restarts. If the
condition that caused a failure has not been resolved, the unit of work remains in
backout- or commit-failed state. See “Backout-failed recovery” on page 79 and
“Commit-failed recovery” on page 83 for more information.
Rebuilding the CICS state after an abnormal termination
The individual resource managers, such as file control, and the CICS domains are
responsible for recovering their state as it was at an abnormal termination.
The process of rebuilding the state for the following resources is the same as for a
warm restart:
v Transactions
v Programs
v Monitoring and statistics
v Journal names and journal models
v URIMAP definitions and virtual hosts
The processing for other resources is different from a warm restart.
Files
All file control state data and resource definitions are recovered in the same way as
on a warm start.
62 CICS TS for z/OS 4.1: Recovery and Restart Guide