Shared Dasd Requirements for Running CA MIM for Z/VM

Document ID : KB000044104
Last Modified Date : 14/02/2018
Show Technical Document Details

Summary:

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.

Instruction:

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:

  1. In z/OS systems, the device must be defined as shared in the SYSGEN IODEVICE macro.

  2. 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:

  1. 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.

  2. 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.

  3. 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.