Modifying an application to use DFSMStvs

You can modify an application to use DFSMStvs by specifying RLS in the JCL or the ACB and having the application access a recoverable data set using either open for input with CRE or open for output from a batch job.

If you want an application that currently uses nonshared resources to use DFSMStvs, consider these points:

Write the application so that it uses RRS services and understands sync points. Write the application so that it issues commit or backout requests at regular intervals. An application that does all of its work under a single unit of recovery can significantly impact other applications and system resources. Holding locks for an excessive period of time could lock out other applications. An extremely long-running unit of recovery could result in your using significant processor storage to maintain control blocks, as well as overusing the undo log stream.
Write applications that use DFSMStvs so that they can function in a multiple-updater environment. Do not convert an application that cannot function in this environment to use DFSMStvs. For example, do not convert an application that uses DISP=OLD, if you cannot convert it to use DISP=SHR.
Use the no read integrity (NRI) level of integrity for read processing. Using NRI gives the application similar locking rules with RLS and DFSMStvs as it does with nonshared resources. Using the consistent read (CR) or consistent read explicit (CRE) level of integrity can result in waiting for the availability of a record. Waiting could result in a deadlock, a timeout, or a retained lock condition with other applications.
Do not use open and record management requests if you do not write the application to handle a return code of 16 from these requests. Return code 16 implies that either RLS or DFSMStvs is not currently available. You do not need to be concerned with the application handling a return code of 16 for nonshared resources.
Use SHOWCB or TESTCB macros to access control blocks other than the user access method control block (ACB), request parameter list (RPL), and exit list (EXLST). These control blocks are not available to the application other than through the facilities provided on SHOWCB or TESTCB macros.
Understand that for update processing, unlike nonshared resources, the application waits for an exclusive record lock if another user has the record locked. The application is then subject to deadlock or timeout return codes.
Understand that if you code a user processing exit routine (UPAD) exit, RLS and DFSMStvs ignore it.

Use care if a batch job uses multiple RPLs. Using different RPLs to access the same record can cause lock contention within a unit of recovery. Because sync points (commits or backouts) cause all locks to be released, the application cannot depend on locking across a sync point.