Enterprise IT Consultant Views on Technologies and Trends

Jun 15 2011   8:52AM GMT

Understanding VSAM RLS that provides limited sharing between CICS and batch



Posted by: Sasirekha R
Tags:
CICS
High Availability
IBM
VSAM

Understanding VSAM RLS that provides limited sharing between CICS and batch

CICS applications are estimated to handle more than 30 billion transactions per day and process more than $1 trillion worth of business every week. VSAM is where the data is for a large percentage of these CICS application. It is also confirmed by the 2010 z/Journal CICS survey where 74% of the respondents found that CICS applications and batch having concurrent access to VSAM data as very important.

VSAM Record-level sharing (RLS) enables VSAM data to be shared, with full update capability, between many applications running in many CICS regions. Before RLS, sharing VSAM data between CICS regions typically meant allocating the VSAM to one CICS file-owning region (FOR) and function ship file requests from other CICS regions to the file-owning region using MRO or APPC connections.

With RLS, the VSAM files are owned by the Storage Management Subsystem (SMS) VSAM server address space, that can be automatically initialized during IPL. To use RLS:

  • requires DFSMS 1.3 or later
  • The sharing CICS regions must all run in the same parallel sysplex
  • There must be one SMSVSAM server started in each MVS image
  • RLS=YES should be specified as a CICS system initialization parameter
  • Specify RLSACCESS(YES) in the CICS file resource definition to provide full update capability for data sets accessed by multiple CICS regions.

As files in RLS mode are accessed simultaneously by multiple CICS regions, SMSVSAM implements locking through coupling facility lock structures. This central lock structure (the IGWLOCK00 lock table) provides sysplex-wide locking at a record level (and not Control interval level as in non-RLS mode). Record locks within RLS are owned by a named Unit of work (UOW) within a named CICS region and CICS releases all locks on completion of a UOW using a VSAM interface.

SMSVSAM also maintains a cache in the coupling facility to hold shared data. Additionally, the SMSVSAM server allocates a local data space that holds the VSAM buffers and control blocks. The strings required for VSAM data access are dynamically allocated (and no need to define strings as for non-RLS files).

VSAM supports two types of lock for files accessed in RLS mode:

  • Exclusive locks – Exclusive locks protect updates to file resources, both recoverable and non-recoverable. It can be owned by only one transaction at a time. A transaction must wait if another task currently owns an exclusive lock or a shared lock against the requested resource.
  • Shared locks – Shared locks support Read Integrity. Can be used to prevent updates of a record between the time that a record is read and the next syncpoint. They ensure that a record is not in the process of being updated during a read-only request.

Shared locks support three levels of Read Integrity:

  • UNCOMMITTED – No read integrity. Shared lock are not used for read requests and this can be used for “dirty” reads.
  • CONSISTENT – A request to read a record is queued if the record is being updated by another task – ensuring that no uncommitted data is ever returned.
  • REPEATABLE – Read processing is similar to CONSISTENT, but in addition the reader holds on to its shared lock until syncpoint. This ensures that a record read in a UOW cannot be modified while the UOW makes further read requests. It is useful when a series of related read requests is issued and it is needed to ensure that none of the records is modified before the last record is read.

VSAM RLS supports active and retained states for locks. While a request for a resource that has an active lock is queued until the resource becomes available, a request for a resource that has a retained lock fails immediately. Exclusive locks can be active or retained, whereas the shared locks can only be active.

VSAM RLS is primarily expected to be used for sharing between CICS applications. By not having to limit the update to a single CICS file-owning region, even distribution of load across CICS regions and improved availability can be achieved.

IBM doesn’t recommend the usage of RLS with entry-sequenced data sets (ESDS) as it has negative impact when adding records – longer response time due to lock acquisition (performance impact) and the ESDS might get locked when a CICS region fails while writing and require restarting CICS (availability impact).

VSAM RLS also enables sharing of VSAM file between CICS and batch applications, though to only a limited extent. VSAM RLS provides the record locking and buffer coherency functions across CICS and batch. But the transactional recovery function for applications is provided by CICS. CICS creates a backout log record for each change made to a recoverable file, and VSAM RLS obtains and holds a lock on each changed record. The lock remains held until the transaction ends. If a transaction fails, CICS backs out all changes made by the application to recoverable files, thus isolating the other sharing applications from the failure.

VSAM RLS permits read and write sharing of non-recoverable data sets (where transactional recovery does not apply) across CICS and batch jobs. While VSAM RLS permits sharing, the jobs must be carefully designed to achieve correct results in a read/write data sharing environment, because they do not have the isolation provided by transactional recovery.

For recoverable data set, in addition to the data sharing across CICS applications, VSAM RLS enables read-with-integrity sharing by batch jobs. Batch jobs can share recoverable files (read-only) while they are being modified by CICS applications. But as VSAM RLS does not provide the transactional recovery function for batch jobs, it does not allow a batch job to open a recoverable data set for output.

The RLS JCL parameter allows batch read programs to use RLS without requiring a recompile of the program. For batch update programs running against nonrecoverable VSAM RLS spheres, the allocation should be modified from DISP=OLD to DISP=SHR.

To update a recoverable VSAM RLS managed files in batch, the file has to be de-allocated in CICS. During the batch processing, with a SHAREOPTION 2,3 CICS can access the file for read-only by opening it in non-RLS mode.

With z/OS V1R10, the option of defining multiple, secondary lock structure for VSAM RLS workloads, based on the number of systems that need RLS is introduced with the aim of reducing locking constraints. Secondary lock structures are intended for record locks only. Other types of locks continue to use IGWLOCK00, which is still required for the initialization |of the SMSVSAM address space. A secondary lock structure, persists beyond data set closure, and can be specified using the SMS storage class attribute called the lock set (up to 256 lock sets per sysplex).

1  Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Sasirekha R
    [...] IT Consultant Views on Technologies and Trends « Understanding VSAM RLS that provides limited sharing between CICS and batch Jun 16 2011   12:26AM [...]
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: