VSAM RLS

Record-level sharing (RLS) is a VSAM function, that enables VSAM data to be shared, with full update capability, between many applications that are running in many CICS® regions.

Accessing VSAM files concurrently from separate CICS regions with full data integrity was possible by implementing a file owning region (FOR). All access to the VSAM dataset was through the FOR. The CICS transactions run in application owning regions (AORs) and the VSAM file requests are function shipped to the FOR. This implementation has several problems, such as:
  • The FOR is a single point of failure.
  • The FOR can be a bottleneck for CPU and throughput.
  • Function shipping between AOR and FOR is additional overhead.

VSAM RLS is designed to allow VSAM data to be shared, with full update integrity, among many applications that running in one, or more z/OS® images in a Parallel Sysplex®, without the need for an FOR in CICS. VSAM RLS provides a transactional interface to multiple CICS regions, including regions that are running on different LPARs. This is important for availability because a multiple LPAR sysplex provides better resilience than a single LPAR. VSAM RLS uses an SMSVSAM address space in each LPAR. AORs in the region connect to the SMSVSAM address space instead of to an FOR.

VSAM RLS components

DFSMS VSAM provides:
  • N-way data sharing
  • Sysplex-wide record-level locking
  • An SMSVSAM address space in each z/OS system, with a shared buffer pool
  • Recovery attributes in the catalog entry - LOG(NONE | UNDO | ALL) and LOGSTREAMID for LOG(ALL). Recovery becomes a dataset property rather than a file property
  • Read integrity options
  • Merging of log records onto forward recover log streams
CICS provides:
  • Logging of VSAM dataset changes for backout and recovery.
  • Backout of uncommitted changes at transaction abort, AOR restart etc.
  • Forward recovery logging and file auto-journalling.
CICS VSAM Recovery for z/OS (CICS VR) (or an equivalent forward recovery product) provides:
  • Inventory of image copies and CICS logs.
  • Automated dataset restore and forward recovery.
  • Uses required RLS commands to unbind and rebind any unresolved locks etc.

Considerations for migrating from non-RLS to RLS access mode

When you are migrating from non-RLS to RLS access mode, potential AFCG abends might occur if a transaction issues a sequence of file control requests that would cause the file to deadlock itself. To help with your migration, enable the following feature toggle to avoid AFCG abends: 
com.ibm.cics.rls.delete.ridfld=true
Why AFCG abends might occur following RLS migration?
If a file is being accessed in non-RLS mode, an AFCG abend is caused by a transaction making conflicting requests against the same control interval (CI). For example, if a file is being accessed in LSR mode, a self deadlock might arise when a transaction issues a DELETE request on a record in the CI that is also the subject of a READ UPDATE request issued by the same transaction. However, if the system initialization parameter CILOCK=NO is in effect to prevent non-RLS VSAM from retaining the CI lock after a READ UPDATE command, the AFCG abend would not be returned as no self-deadlock condition occurs on the DELETE request. However, CILOCK is not relevant for RLS, so after the files are migrated to RLS access mode, AFCG abends can occur for the reasons given above.
What's the solution?
To help with your migration, you can enable the feature toggle com.ibm.cics.rls.delete.ridfld=true to achieve the local VSAM's CILOCK=NO behavior for RLS files. This allows the DELETE requests to be successful in such circumstances.

See Specifying feature toggles for instructions on how to specify feature toggles.

Learn more

For information about setting up VSAM RLS support in CICS, see Definitions required for VSAM RLS support.

For more information about CICS VR, see CICS VSAM Recovery for z/OS.