How does SYSB-II compare to other alternatives?
VSAM RLS gives you the ability to define VSAM files (data sets) as either "recoverable" or "non-recoverable." If the files are defined as non-recoverable, you can process batch while the files are still available to CICS. However, non-recoverable files do not support forward or backward recovery. Therefore, you should not define files that contain critical data as non-recoverable. VSAM RLS is not a substitute for SYSB-II. SYSB-II can run with or without VSAM RLS.
SHAREOPTION 3, on the surface, appears to solve the limitations of SHAREOPTION 2 by enabling multiple, concurrent updates. But 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. Employment of SHAREOPTION 3 may lead to corrupted VSAM integrity and increased overhead.
SHAREOPTION 4 requires extensive and complex programming modifications that will increase I/O overhead to ensure data integrity. Use of this SHAREOPTION 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 of the transaction updated records with initial values - even if the records have been subsequently updated by a batch job.
Transactional VSAM (TVS, or DFSMStvs) is IBM’s solution to file sharing. Modifications or rewrites can be extensive depending on the batch job. Also, TVS uses a longer I/O path. This will slow down data centers running at capacity during peak demand times, regardless of file sharing. In order to use TVS, you must have VSAM RLS. In contrast, SYSB-II can run with or without VSAM RLS, and you don’t need to make source-code changes.