ABCs of z/OS System Programming Volume 3 - IBM Redbooks

7.11 Transactional recovery
Commited transaction Failed transaction (back out)
Trans1:
Read Record 1
(Lock Record 1)
(Log Record 1)
Write Record 1'
Read Record 2
(Lock Record 2)
(Log Record 2)
Write Record 2'
Commit
(update log)
(release locks)
Record 1 Record 1'
Record 2 Record 2'
Figure 7-11 Transactional recovery
CICS transactional recovery for VSAM recoverable data sets
During the life of a transaction, its changes to recoverable resources are not seen by other
transactions. The exception is if you are using the no-read integrity (NRI) option. Then you
might see uncommitted changes.
Exclusive locks that VSAM RLS holds on the modified records cause other transactions that
have read-with-integrity requests and write requests for these records to wait. After the
modifying transaction is committed or backed out, VSAM RLS releases the locks and the
other transactions can access the records.
If the transaction fails, its changes are backed out. This capability is called transactional
recovery.
The CICS backout function removes changes made to the recoverable data sets by a
transaction. When a transaction abnormally ends, CICS performs a backout implicitly.
Example
In our example in 7.11, “Transactional recovery” on page 394, transaction Trans1 is complete
(committed) after Record 1 and Record 2 are updated. Transactional recovery ensures that
either both changes are made or no change is made. When the application requests commit,
both changes are made atomically. In the case of an failure after updating Record 1, the
change to this record is backed out. This applies only for recoverable data sets, not for
non-recoverable ones.
394 ABCs of z/OS System Programming Volume 3
Trans1:
Read Record 1
(Lock Record 1)
(Log Record 1)
Write Record 1'
Record 1 Record 1'
---------------------------------- Failure ------------------------------------
Read Log Record 1
Re-Lock Record 1
Write Record 1
Commit
(update log)
(release locks)
Record 1 Record 1