Concurrent access to VSAM files from batch and CICS

SYSB-II ® is mainframe software that allows CICS and batch to have concurrent access to VSAM files, while maintaining data integrity. This means you can process batch whenever needed, while CICS applications and VSAM data remain fully available for updates.

Traditionally when batch updated VSAM files, organizations had to take CICS applications offline or
employ techniques like showing read-only data to CICS users. SYSB-II changes all of that.

With SYSB-II, organizations can:

-Keep CICS applications running 24/7 so they can be available on PCs and mobile devices, without
downtime.

-Accept new business because organizations have more time both to process online transactions and run batch.

-Expand to more time zones because CICS applications can be online during traditional “nighttime” hours.

How SYSB-II works

SYSB-II uses the documented MVS subsystem interface to intercept batch VSAM requests, translate the input/output (I/O) requests into CICS I/O protocol, and then allow CICS to perform the VSAM operation on behalf of the batch job. SYSB-II communicates between CICS and the batch job using TCP/IP, VTAM, and cross-memory services. This architecture ensures that SYSB-II is upwardly compatible with future releases of CICS Transaction Server and z/OS.

SYSB-II runs as a legitimate command-level CICS transaction, following CICS rules and standards. Batch jobs look any other CICS transaction to the CICS application.

With SYSB-II, batch can take advantage of CICS’s data integrity, recovery tools, and file-locking and updating capability. SYSB-II also supports, but doesn’t require, VSAM RLS, a CICSplex, a sysplex, coupling facilities, and TCP/IP and VTAM protocols.

How VSAM RLS works

VSAM RLS is a function introduced by DFSMS/MVS V1.3 and exploited by CICS Transaction Server. It is designed to enable VSAM files to be shared, with full update capability, between many applications running in many CICS regions. Prior to the inception of RLS, VSAM data sets that were opened for update were owned and accessed through a single address space, either by stand-alone batch or by a CICS file-owning region (FOR). With RLS, the VSAM files are owned by the RLS server address space (also known as SMSVSAM). Multiple CICS regions can access the data concurrently with full update integrity, thereby eliminating the CICS File Owning Region that had become a bottleneck and a single point of failure for many installations.

Logging 

VSAM RLS files fall under two main categories: recoverable and nonrecoverable. The recoverability of an RLS VSAM file depends entirely on the value specified for the LOG parameter in the VSAM cluster definition. This parameter was introduced to support RLS and has three possible values: NONE, UNDO, and ALL. A recoverable data set is one whose in-flight changes are backed out (by CICS) if a transaction fails. The LOG value used on the RLS recoverable VSAM file definition is either UNDO or ALL.

• NONE - A value of NONE identifies the data set as nonrecoverable because CICS does not log any changes for the data set and is unable to provide transactional or data set recovery.

• UNDO - The data set is backward recoverable. That is, any in-flight changes made by a unit of work that does not succeed (uncommitted) is backed out. Changes added to the CICS logger are used to back out any in-flight unit of work that failed. This is also known as transactional recovery.

• ALL - The data set is both backward and forward recoverable. Forward recovery is possible only when another product such as CICS VSAM RECOVERY (CICSVR) is used. When ALL is used, CICS records both the before and after images of any change. In addition to transactional recovery, ALL allows the capability for products such as CICSVR to rebuild data if hardware fails or software problems occur against the data set. This type of recovery is known as data set recovery

Locking 

Files opened in RLS mode can be accessed by many CICS regions simultaneously. This means it is impractical for individual CICS regions to attempt to control record locking. Therefore, VSAM maintains a single, central lock structure using the lock-assist mechanism of the coupling facility. This central lock structure provides sysplex-wide locking at a record level. No control interval (CI) locking is used. This is in contrast to the locks for files in non-RLS mode, which are normally limited to a single CICS region and are either CI locks or CICS ENQs.

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

• Shared locks
Shared locks support read integrity. They ensure that a record is not in the process of being updated during a read-only request. Shared locks can be owned by several tasks at the same time.

• Exclusive locks
Exclusive locks protect updates to file resources, both recoverable and nonrecoverable. They can be owned by only one transaction at a time. Any transaction that requires an exclusive lock must wait if another task currently owns an exclusive lock or a shared lock against the requested resource.

Exclusive locks can be active or retained, whereas shared locks can only be active. When a lock is first acquired, it is an active lock. Normally this lock would eventually be released, but if a unit of work fails, and this would cause the lock to be held for an abnormally long time, the active lock is converted into a retained lock. This has implications for batch processes that require RLS files to be quiesced prior to batch execution because a quiesced data set can be opened only in non-RLS mode if no retained locks are present.

Integrity 

To request access to a RLS VSAM data set, a batch program must do one of the following: • Specify the RLS read integrity level on the MACRF parameter of the VSAM ACB. • Add an RLS parameter to the DD statement for the file in JCL. If the RLS parameters are omitted then the program will attempt non-RLS access to the file. Depending on the type of OPEN (read or update) and the recovery attribute of the RLS file, this situation could give rise to program abends or, potentially worse, access to data in native VSAM mode with none of the integrity benefits of accessing the shared RLS SMSVSAM buffers.

For files opened by CICS, the read integrity level is specified in the file definition.The RLS recovery option (if not specified) is taken from the VSAM file definition stored in the ICF catalog.

RLS read integrity 

VSAM RLS supports three levels of read integrity:

• NRI (No Read Integrity)
No record locking is performed by VSAM when a GET/POINT request is issued. Although this avoids the overhead of locking, it can allow the requestor to obtain uncommitted data and is sometimes referred to as a dirty read.

• CR (Consistent Read)
A shared lock is obtained by VSAM for GET/POINT requests. This ensures that no uncommitted data are ever be returned to the application. GET/POINT requests wait for any pending change to be committed or backed out and the currently held lock to be released.

• CRE (Consistent Read Explicit)
This is similar to CR except that the shared lock is held by VSAM RLS until the unit of recovery or unit of work has been completed. This type of lock is available only to CICS and TVS.

Update integrity 

For updates to a recoverable file, data integrity is ensured by SMSVSAM by maintaining locks on data changed in the unit of work until CICS explicitly declares that locks can be released. CICS signals this as a result of one of the following:

• Successful completion of the unit of work
• Processing of a SYNC call
• Successful backout of in-flight changes, should a unit of work fail

RLS provides locking and sysplex-wide parallel shared-data access, while CICS provides the logging and recovery capabilities. It is both of these features used together that make transactional recovery of a VSAM RLS data set from a failed unit of work possible.

For updates to a nonrecoverable file, RLS releases a lock when the buffer containing the modified control interval has been written. Because no transactional recovery is ever performed on a nonrecoverable file, changes are not backed out and there is no need to maintain any locks. In fact, it is reasonable to assume that locks against records in a nonrecoverable data set remain held only for the duration of the requests — that is, they are acquired at the start of a request and released upon its completion.

SHAREOPTION 

SHAREOPTION is largely ignored under RLS, with the exception of SHAREOPTION (2, x). This means that non-RLS reads of a data set opened in RLS mode are possible. No data integrity is provided for the non-RLS reader. Both CICS and batch can have concurrent read and update access to nonrecoverable data sets. Again, in this instance, no coordination between CICS and batch occurs, so data integrity issues are possible.

Batch and VSAM RLS recoverable files 

As previously stated, RLS addresses the limitation of a single CICS address space owning a VSAM file for update and the associated single point of failure. For recoverable VSAM files, CICS read and update integrity is ensured by synchronized SMSVSAM buffers and the coupling facility’s system-wide locks on accessed records. With VSAM RLS, you no longer need to restrict VSAM update activity to a single CICS file-owning region. Now you have the possibility of channeling your workload to any number of additional available CICS regions, allowing you to better balance the workload and evenly distribute access to VSAM data.

For batch processes that require inquiry access to RLS-managed recoverable VSAM files, read integrity can be obtained through RLS implementation by utilizing the shared SMSVSAM buffers. In other words, shared access is allowed for read only from a batch program.

For batch processes that require update access to RLS-managed recoverable VSAM files, a batch processing window is still required. This requires deallocation of the VSAM file from RLS (and CICS) while batch updates the file natively. When batch is completed, the VSAM file can be reopened under RLS management. If CICS requires inquiry access to the VSAM file during batch processing, this can be achieved with a SHAREOPTION 2,3. However, the VSAM file must be opened under CICS as non-RLS mode for inquiry only. This is typically achieved by providing a separate FCT entry for CICS inquiry during batch processing.

Batch and VSAM RLS nonrecoverable files 

For nonrecoverable files, batch and CICS can process concurrently for both read and update capabilities. By definition, recovery is not ensured for either a CICS transaction or a batch transaction. With nonrecoverable files, if a transaction updates multiple records and fails before the last record update is successful, the unit of work is partially committed.

 For example, a single transaction is made to transfer $100 from a savings account to a checking account. This single transaction issues two record update requests. The first record update adds $100 to the checking account and adjusts the account balance accordingly. The second record update subtracts the $100 from the saving account and adjusts the balance accordingly. If the files are defined as nonrecoverable, the $100 might be added to checking but the subsequent $100 subtraction to the savings account is unsuccessful. This increases the checking account by $100 but the associated equivalent savings account debit does not occur.

This potential exposure escalates with batch in a shared environment. Records are committed with every successful write, rewrite, or delete request. If an abend occurs, the status of files might be in a state that is less than ideal when auditing takes place. This might not be an issue for batch jobs that can be rerun at the point of failure or rerun without adverse affects to the data. However, such is not typically the case.

In other words, recovery becomes your responsibility when batch and CICS share update access through RLS for nonrecoverable files. If you choose to restore a file to a point-in-time backup, what happens to the updates that have occurred after the point-in-time backup was established? Implications to sharing nonrecoverable VSAM files for update between batch and CICS need to be carefully considered.

Understanding VSAM SHAREOPTIONs

SHAREOPTIONs are settings that provide various levels of shared access to VSAM files. This capability has been available for decades, and on initial review, it appears to be an easy way to provide file sharing. Let's take a closer look at the SHAREOPTIONs and exactly what it takes to implement this approach.

SHAREOPTION 1 is the most restrictive of all SHAREOPTIONs, disallowing any file sharing if updates occur. This SHAREOPTION permits a single region to write to a VSAM data set or enables many regions to read a data set. If a region is updating the file, all access to the file is denied to any region seeking to perform a read, so this option is often deemed unacceptable. Yet, performance wise, this is the most effective SHAREOPTION to use.

SHAREOPTION 2 also prohibits concurrent data set updates, but provides for multiple reads during an update process. This function is typically used where CICS is the updating application with infrequent data reading from batch. A major drawback of SHAREOPTION 2 occurs when a reading region attempts to access data that an update region has modified. It is possible that the reading region will not receive the most recent updates and could terminate abnormally if substantial data changes have occurred.

SHAREOPTION 3 on the surface, appears to solve the limitations of SHAREOPTION 2 by enabling multiple, concurrent updates. Because SHAREOPTION 3 permits multiple regions to both read and write to a single data set, it would also permit multiple regions to concurrently update identical blocks of records, causing a loss of physical data. Using SHAREOPTION 3 could lead to VSAM data integrity issues and increased overhead.

SHAREOPTION 4 requires extensive and complex programming modifications to your application. These modifications will increase I/O overhead to ensure data integrity. Use of SHAREOPTION 4 will not enable a single CICS region to lock onto its required records. An environment using SHAREOPTION 4 and enabling concurrent updates by both CICS and batch could experience a severe data integrity problem in the event of a CICS transaction abend. The CICS dynamic transaction backout will replace all the transaction-updated records with initial values, even if a batch job updated the records.

Practical implications: Employment of a higher VSAM SHAREOPTION translates into increased overhead. Additionally, the risk of error increases when there is less data-integrity protection. Employing VSAM SHAREOPTIONs for concurrent update access between CICS regions and batch jobs is rarely a suitable solution for companies striving to ensure processing efficiency and data integrity.