IBM SC34-7012-01 Other backout processing, Effect of delayed recovery on PLTPI processing, Files

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:

vTransactions

vPrograms

vMonitoring and statistics

vJournal names and journal models

vURIMAP 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.

62CICS TS for z/OS 4.1: Recovery and Restart Guide