VM provides support for the Parallel Access Volumes (PAV) feature of the IBM Enterprise Storage Server (ESS). ESS DASD need to be defined to VM as 3390 model 2, 3, or 9 DASD on a 3990 model 3 or 6 control unit. 3380 track-compatibility mode for the 3390 model 2 or 3 DASD is also supported. The PAV feature of the ESS is supported on VM for guest use via dedicated (otherwise known as attached) DASD.

Figure 1. illustrates the PAV Base to Alias volume relationship. The Base volume can be thought of as the real physical DASD space. It has its own unique subchannel ID. Alias volumes X and Y in the figure can be thought of as volumes that map the physical space occupied by the Base. The Alias volumes don't have their own space; they are 'shadows' of the Base. However, they also each have unique subchannel Ids so that I/O can be done concurrently to all three volumes (Base, Alias X, and Alias Y).

For VM, the Base volumes are defined in IOCP as UNIT=3990 on the CNTLUNIT statement and UNIT=3390B (or 3380B) on the IODEVICE statement. Alias volumes are defined as UNIT=3990 on the CNTLUNIT statement and UNIT=3390A (or 3380A) on the IODEVICE statement. UNIT=2105 on the CNTLUNIT statement is also acceptable. Each volume can be assigned any available VM real device number. The designation of which real volumes are Base volumes, which are Alias volumes, and which Alias volumes are associated with each Base must be initially defined using the ESS configuration console. The CP QUERY PAV command can be used to view the current real Base and Alias volume allocation under VM.

The main purpose of the ESS PAV feature is to increase system throughput and reduce I/O bottlenecks by allowing multiple concurrent I/O operations to the same physical DASD space. This use of the PAV feature will be referred to as 'workload balancing' in the description below.

Figure 2 illustrates a guest running on VM that uses PAV volumes for workload balancing. For this application, the Base volume and all its associated Alias volumes (Alias X and Alias Y) will be dedicated via the CP ATTACH command to the guest (VM Guest). The virtual device numbers and subchannel IDs assigned to the PAV volumes are immaterial. The guest will schedule I/O on whichever of the Base and Alias volumes seems most appropriate in order to maximize workload performance. I/O may be scheduled concurrently on some or all of the associated PAV volumes.

It should be noted that the VM Guest in Figure 2 must contain support code to manage and serialize the workload data across the PAV volumes. VM only acts as the 'pipe' between the guest and the hardware. Once the necessary Base and associated Alias volumes are attached to the guest, it is the guest that must manage their use.

An example of a guest operating system that contains the necessary support for PAV workload balancing is z/OS. In addition to the workload support just described, a z/OS guest also has the ability to dynamically move an Alias volume from its current Base volume to a different Base volume if the workload demands it. The CP QUERY PAV command can be used to keep track of the dynamic movement of Alias volumes performed by a z/OS guest.

Another use of the ESS PAV feature is for sharing data across multiple host operating systems. This use is primarily applicable to the VM platform because of its ability to run multiple operating system guests. The main advantage of sharing data in this way is that the PAV volumes are eligible for I/O Assist when attached to Preferred VM guests.

Figure 3 illustrates the use of PAV volumes for sharing data among multiple VM guests. In the example, Alias X has been attached via the CP ATTACH command to Guest A. Alias Y has been attached, again via ATTACH, to Guest B. Both Alias X and Y are associated with the same Base volume (not shown, but can also be used for sharing) which is attached to neither guest. The VDISK (Virtual Disk In Storage) in the example is linked to both Guest A and B via the VM User Directory.

The linked VDISK is important because it demonstrates a method for serializing the data that is shared among the two guests. The VDISK could contain, for example, the VSE lock file. The VDISK would not be necessary in a read-only environment. In that case, the Alias volumes could just be attached to the guests using the R/O option of the ATTACH command. A method to serialize access to the Alias volumes must be devised, because Reserve/Release is not supported on PAV Alias volumes (the CCWs will be rejected). By using a linked VDISK, Reserve/Release can be used against the VDISK to control access to the Alias volumes. Also, it must be insured that free (not attached) Base and Alias volumes associated with the PAV volumes being shared are clear of all write activity.

In summary, it is the sole responsibility of the VM guests to manage and serialize any data that is shared via Alias volumes. VM only provides the 'pipe' for data exchange between the hardware and the guests. Also, the above described method of DASD sharing will not work with z/OS guests since each z/OS guest must have access to the Base volume.

1. An Alias volume can not be IPLed.
2. An Alias volume can not be attached to the userid SYSTEM.
3. An Alias volume can not be attached to a guest if its associated Base is currently attached to SYSTEM. Alternatively, a Base volume can not be attached to SYSTEM if any of its associated Alias volumes are attached to one or more guests.
4. An Alias volume will not come on-line to VM without an associated Base volume. Also, a Base volume must have at least one associated Alias volume for VM (e.g., QUERY PAV command) to recognize the device as a Parallel Access Volume.
5. A Base volume can not be changed or deleted with the SET RDEVICE, DELETE RDEVICE, DELETE DEVICE, or MODIFY DEVICE command unless all associated Alias volumes have been deleted via the DELETE RDEVICE command.