If running COMMUNICATION=CTCDASD or COMMUNICATION=DASDONLY, all processors that will run CA MIM for z/VM and its associated components must share at least one volume of DASD in count-key-data (CKD) format. This DASD, where the CA MIM control file will reside, must support reserve and release processing, a feature that serializes access to the DASD.
CA MIM for z/VM control files must be allocated on a shared DASD device that is accessible to all systems on which CA MIM executes. When a DASD device is shared among systems, remember the following guidelines:
- In z/OS systems, the device must be defined as shared in the SYSGEN IODEVICE macro.
- In z/VM systems, the device must support reserve/release processing.
The two types of reserve/release processing are:
- Real reserve/release processing, which is needed when CA MIM for z/VM is running on two or more real processors (that is, two or more systems that are not guests under the same z/VM system).
- Virtual reserve/release processing, which is needed if two or more operating systems operate as guests of z/VM.
If you have several guests running under one z/VM operating system, and have at least two real processors in your installation, you should use both real and virtual reserve/release processing.
With the above guidelines in mind, configure the DASD for your control files as follows:
- Whenever control files are shared by two or more real processors, specify SHARE YES in the system configuration file or SHARED=YES in the HCPRIO ASSEMBLE file for all RDEVICE macros that you are using to define DASD for control files. SHARED=YES or SHARE YES must be specified on each guest system, even if the first level z/VM system does not share DASD with any other processor or LPAR.
Note: The SHARED=YES or SHARE YES parameter is required to propagate reserve commands to the DASD hardware and upward to the host z/VM system.
- When your installation runs two or more operating systems as z/VM guests on the same real processor, specify virtual reserve/release processing for the minidisks used as a control file (whether or not other processors are in use). To do so, specify mode MWV on the MDISK statement in the z/VM directory entry for one of the guest operating systems. Then, using mode MW, issue a link command to the same minidisk from each of the other guest operating systems.
Using virtual reserve/release processing protects guests on the same real processor from each other. Also, hardware reserve still operates correctly when virtual reserve/release is invoked, thus protecting users in separate real processors from each other.
- Always specify virtual reserve/release processing for the control file minidisks even if there are no guest operating systems under z/VM. To do this, specify mode MWV on the MDISK statement that defines the minidisk. Reserve/release channel commands are not processed correctly unless virtual reserve/release is specified.