VSAM and File and DASD Sharing

First, always remember that file sharing is a functional feature, not a performance enhancement. Choosing to share a file concurrently with another VSE application in the same or another VSE image will permit your application(s) to function together, but there will be a performance impact -- in some cases, a very noticable performance impact.

VSE and VSAM support sharing of files and disk volumes with integrity. The integrity is ensured through the use of a VSE Supervisor table (the Lock Table) when the tasks sharing a resource are running within a single VSE image. When sharing among tasks which may run in more than one VSE image, VSE's Lock Manager uses an external resource (the VSE Lock File) which is used in common by all the sharing VSE images.

In this discussion, note that it does not matter whether the various VSE images run in multiple real CPUs, in separate Logical Partitions (LPARs) of the Processor Resource/System Manager (PR/SM) facility, as separate guests under control of one or more VM systems, or some mixture of them.

Often, users choose the flexibility option. It can be very simple to set this environment up to permit full sharing of all your disk devices -- which allows great operational flexibility in that any job can potentially run in any VSE image.

This flexibility comes at a price, however. There will be additional I/O (and overhead for it) associated with VSE inter-system locking mechanism. In the ideal case, this can be minimized if separate disks are defined for each image and ony those files which MUST be shared are placed on disks which are shared. Then, lock I/O activity will only occur for those files which must be shared.

Consider the situation when careful discrimination between files which MUST be shared and other files which could be kept separate is ignored:

• All (or almost all) disks are defined as shared.
• All access to any files on those disks require sharing services.
• OPEN processing times are elongated.
• Throughput is reduced due to higher CPU consumption and longer delays during critical processing, such as OPEN.

General Sharing Considerations

If you can, you should not share volumes among multiple VSE images.

Both data integrity and system performance are always impacted, sometimes in subtle ways.

Many VM/VSE users in the past chose to provide a single pool of workfile space for VSAM and/or SAM workfiles which was shared among all the VSE images. To be sure, the pooling concept saves DASD space, but does impact performance when compared with choosing to implement separate workfile space pools for each VSE image which need not be specified as shared. In the conditions of shared workfile space pools, the VTOCs and catalogs for the shared volumes can readily become very significant bottlenecks impacting batch throughput and critical path time through your batch processing window.

With modern DASD, it may be economical to re-evaluate this choice -- using more "virtual DASD" volumes that do not need to be shared may be a better way, even though additional DASD may be required.

With some care in planning, you can arrange compiles, sorts, and other users of workfile space pools so that they do not normally share data volumes.

Remember that if only one file on a volume needs to be shared, the volume must be shared, even though all the other files on that volume are used by only one VSE image.

VSAM SHAREOPTIONS

VSAM provides five levels of sharing and locking, with increasing sharability (and significant increases in overhead) as you change levels:

SHAREOPTION(1)

This provides the highest level of integrity, READ integrity, since at no time is it possible for a reading task to see data which may be obsolete. To be able to provide this level of integrity, no user is permitted to open a file for any access when it is opened for output by another task, and if the file is opened for input, other tasks can open it for input but no task can open it for output.

Locking is only performed during OPEN and CLOSE, so there is little to no performance impact from this choice.

SHAREOPTION(2)

This provides a high level of integrity, WRITE integrity, since at no time is it possible for any updating task to see data which may be obsolete. To be able to provide this level of integrity, no user is permitted to open a file for output when it is opened for output by another task, and if the file is opened for input, other tasks can open it for input and at most one task can open it for output.

Locking is only performed during OPEN and CLOSE, so there is little to no performance impact from this choice.

SHAREOPTION(3)

This VSAM option provides NO integrity for your data. Shareoption(3) does no VSAM integrity checking and provides no integrity services. Any number of users may open and update the file simultaneously. To ensure integrity, the users must provide their own mechanism to prevent concurrent update of file and control data.

As no checking is done by VSAM, there is no performance impact from this choice. Generally, SHAREOPTION(3) should be used only by subsystems which provide their own integrity checking, such as the VSE Librarian.

SHAREOPTION(4)

This option provides a high level of integrity (WRITE inegrity) for data being updated, while providing no special protection for data only being read. Many tasks in several VSE images can open the file for read access. Simultaneously, one or more than one task in one VSE image may open the file for output. All output users are granted WRITE integrity, but read-only tasks do not have READ integrity.

The cross-system image integrity checking is only done during OPEN and CLOSE, so this incurs little performance impact. However, in order to ensure READ and WRITE integrity for update processing, VSAM will always refresh buffer contents from disk for any GET, and then will LOCK the CI until PUT (or RELEASE) processing. In addition, from the time PUT processing begins until it finishes, the CA will be locked. The locking done is INTERNAL locking, using VSE's lock table.

The extra overhead processing time and I/O activity is as a result of the forced refresing of buffer contents, and not from locking per-se. Clearly, this option adds CPU time and I/O wait time to processing requests.

SHAREOPTION(4 4)

This option extends SHAREOPTION(4) fully across system images, in that tasks in multiple images can open the file for output processing simultaneously.

Processing for SHAREOPTION(4 4) is similar to that for SHAREOPTION(4) in that buffer refresh processing must be done. At the same time, the internal locks done during functional processing requests in SHAREOPTION(4) are forced to become external locks and thus will incur physical I/O delays during the reading and writing of the VSE Lock File.

So, Smart Swami, what should I do?

This is one place where generalities will clearly have to suffice.

Generally, you should NOT use SHAREOPTION(3). When this option is chosen, VSAM and VSE provide no integrity checking for you, and it is (at least remotely) possible that you or an operator might just happen to schedule two jobs concurrently that OPEN a file for update. You could have been running them like this for months or years without a problem, but one day...

Generally, you should use as low a SHAREOPTION level as possible. SHAREOPTION(1) provides the most integrity, but it restricts you if you need to read a file which is opened for update somewhere else. SHAREOPTION(2) permits concurrent read access while the file is opened for update. However, it is possible that a read-only user may experience any one of the symptoms from the lack of read integrity:

• GET can return a record's old data, even though that record has been updated on disk.
• GETs can return an "incorrect logic" or "boundary exception" type of error when they try to retrieve a record which has been relocated by a CI and CA split since the time that the read-only task OPENed the file.
• Application programs may experience ABENDs, return codes, and other indications which indicate potential for corrupted VSAM file information. Re-running the read-only application usually causes the apparent error to disappear. In some cases, the update application may have to CLOSE the file, in addition to the read-only application being re-run.

SHAREOPTION(4) and (4 4) permit multiple applications to access a file for update safely, but in so doing, incur a significant performance price. Recall that SHAREOPTION(4) and (4 4) files do not provide more protection than SHAREOPTION(2) for files opened with only read intent.

Use the lowest SHAREOPTION level you can to meet the needs of your application suite.

VSAM use of the VSE Lock Manager

To understand this problem, you need to understand a bit about VSE's locking mechanism and how VSAM uses it.

VSE provides two kinds of locks:

1. Internal Locks, used within a single VSE image, for resources not shared among multiple VSE images -- files shared among partitions within a single VSE system, the VTOC of a non-shared volume, etc.
2. External Locks, used across multiple VSE images, for resources which are shared among multiple VSE images -- files on volumes which are shared among multiple VSE systems, library members in libraries which are on volumes which are shared, etc.

VSE's Lock Manager uses an internal lock table for Internal Locks. External Locks are recorded both in the lock table of the owning system and in the VSE Lock File, which (of course) must be located on a DASD volume which is accessible to all the VSE systems sharing resources.

VSAM uses this VSE locking mechanism to implement its integrity features for shared files and other resources.

A standard convention is used by VSAM to create Lock Resource Names. Lock Resource Names are 12 bytes in length, and for file related locks they contain:

• All VSAM lock resource names begin with the character "V".
• All VSAM file related locks contain the 6-character VOLSER of the volume containing the catalog where the file is defined.
• All VSAM file related locks contain a 3-byte CI number referencing the Control Interval number within that catalog where the file is described. This plus the previous (VOLSER) value uniquely define the file.
• All VSAM file related locks contain a 2-byte code for the specific file-related function being locked.

So, what can go wrong?

Well, if that lock resource name really isn't unique, then the VSE Lock Manager may falsely detect that a file has been locked. This is common enough to appear on the Lehigh University VSE-L listserver fairly often.

Simply, if within the scope of a given VSE system or the scope of a group of VSE systems using a VSE Lock File, there are more than one VSAM catalog residing on two different disk volumes, but those different volumes have duplicate VOLSER values, then it is possible for what should have been two different VSAM-created Lock Resource Names to be the same.

This results in VSAM OPEN error x'A8' or 168 error codes being returned to your application. No data is at risk, as your application is prevented from opening the file.

So? What should I do about this? VSAM should be fixed!

No, VSAM is working as you really want it to -- it is protecting your data. You should identify all volumes within the scope of your VSE system and its related VSE Lock File, and insure that they have unique VOLSERs.

If the volumes are not shared (they are really different volumes) then it is permissible for them to have the same VOLSERs, but they MUST be defined in your VSE IPL ADD commands as:

ADD cuu

WITHOUT the ",SHR" parameter.

Note carefully: if the volume is really shared and is not defined as

ADD cuu,SHR

then you are at risk of data and control information being corrupted as the various systems with access to the volume will not post locks to protect your data and system control information on the volume.

Summary

For all disk volumes which are shared among more than one VSE image, you must insure that all the following are true:

• Each volume is defined in each VSE image's IPL ADD commands with ",SHR" specified.
• Each volume has a unique VOLSER.

For all disk volumes which are NOT shared among more than one VSE image, you should ensure that all the following are true:

• Each volume is defined in its (unique) VSE image without ",SHR" specified.
• Each volume within the VSE image has a unique VOLSER.

---