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.