VSAM tableBASE libraries and LSR pools

If a tableBASE VSAM library is allocated with DISP=OLD there are no restrictions on SHAREOPTIONS, buffering, strings and buffer pools.

However if it is allocated as DISP=SHR, tableBASE uses MVS Enqueues (SCOPE = SYSTEMS) and I/O techniques to ensure the library’s integrity is maintained. Our standard recommendation has been to use SHAREOPTIONS(3,3) in all environments to prevent overlays of the tableBASE library directory and table data.

In CICS (and optionally batch), standard performance recommendations have been to add VSAM datasets to buffer pools (LSRPOOLS). However this would undermine tableBASE library integrity, so for libraries that it accesses, tableBASE will reset any LSRPOOLID value to zero, effectively making them NSR (Non-Shared Resources). Any software that changes buffer pool settings dynamically for VSAM datasets will create integrity problems for tableBASE libraries.

tableBASE cannot maintain library integrity with SHAREOPTIONS(3,3) and any VSAM buffering.

However, with CICS/TS 4.1, IBM is enforcing the restriction that CICS Transaction Isolation is not supported for NSR VSAM files. An AFDK abend will be issued when the library is opened. To accommodate this restriction (which does not apply to BDAM tableBASE libraries or libraries allocated with DISP=OLD), tableBASE will ensure library integrity with SHAREOPTIONS(4,4) and LSRPOOLS for the CICS environment.

Based on IBM documentation, we recommend that the buffer pool used with SHAREOPTIONS(4,4) be set to a minimum size and not be shared with other users. The buffers will not benefit tableBASE and could interfere with other applications sharing the buffer pool. The library directory caching feature implemented with Version 6 should provide equivalent or better results than LSR pooling.