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

7.30 Application considerations
Break processing into a series of transactions
Figure 7-39 Application considerations
Application considerations
For an application to participate in transactional recovery, it must first understand the concept
of a transaction. It is not a good idea simply to modify an existing batch job to use DFSMStvs
with no further change, as this causes the entire job to be seen as a single transaction. As a
result, locks would be held and log records would need to exist for the entire life of the job.
This can cause a tremendous amount of contention for the locked resources. It can also
cause performance degradation as the undo log becomes exceedingly large.
Break processing into a series of transactions
To exploit the DFSMStvs capabilities, break down application processing into a series of
transactions. Have the application issue frequent sync points by invoking RRS commit and
backout processing (MVS callable services SRRCMIT and SRRBACK). For information about
RRS, see 7.25, “DFSMStvs use of z/OS RRMS” on page 423.
RLS and DFSMStvs provide isolation until commit/backout. Consider the following rules:
► Share locks on records accessed with repeatable read.
► Hold write locks on changed records until the end of a transaction.
► Use commit to apply all changes and release all locks.
► Information extracted from shared files must not be used across commit/backout for the
following reasons:
– Need to re-access the records
430 ABCs of z/OS System Programming Volume 3
Invoke RRS for commit and back out
Modify program/JCL to request transactional VSAM
access
Specify through JCL or ACB
Prevent multiple RPLs from causing intra-UR lock
contention
Handle potential loss of positioning at sync point
Handle all work that is part of one UR under the
same context
Do not use file backup/restore as job restart
technique