Because DFSMStvs builds on VSAM RLS, many of the planning steps for the implementation of VSAM RLS are common to a DFSMStvs implementation. You should perform the following tasks to plan for using DFSMStvs:

• Determine the hardware and availability requirements for coupling facilities. For DFSMStvs, the coupling facilities not only support lock tables and caching of data but should also be used for logging.
• Determine which applications need the ability to update recoverable data sets concurrent with CICS® usage of those data sets, and then determine which of them can use the DFSMStvs support.
• Determine the size and number of coupling-facility cache structures and their connectivity.
• Determine the size of the coupling-facility lock structure. With the use of DFSMStvs, batch jobs update recoverable data sets while CICS is also using them, which results in increased locking activity.
• Determine the requirements for the SMS configuration, including storage-class specifications of coupling-facility structures, connectivity, and modifications to the ACS routines. If you have already established storage classes for VSAM RLS and coupling-facility cache structures, you can use those for both VSAM RLS and DFSMStvs. You might need to make the structures larger, however, due to increased usage.
• Add new parameters to the IGDSMSxx member of SYS1.PARMLIB for DFSMStvs initialization, quiesce time out, and activity keypointing.
• Convert batch jobs for use of DFSMStvs to update recoverable data sets:
  • Modify each job to recognize sync points and to take the appropriate action, whether commit or backout, by calling z/OS® RRS services.

    Recommendation: Do not perform a commit or backout through an RRS panel.

  • Modify the programs or JCL to specify that DFSMStvs is to be used.
  • Examine each job to ensure that the use of multiple request-parameter lists within a single program will not cause lock contention within that program.
  • Code each job to handle the loss of positioning that occurs at commit or backout for unpaired requests (an unpaired request consists of a GET UPD not followed by a PUT UPD).
  • Examine each job to ensure that it handles any new return and reason codes from VSAM appropriately.
  • Introduce restart logic to prevent duplicate or missing updates in the event of a rerun.
• Update your recovery procedures to make use of forward recovery.