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.