|
Gary:
Thanks, this has made it MUCH
clearer!
David Wakser From: Shiminsky, Gary - OIT [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 06, 2006 1:28 PM To: [email protected] Subject: Re: VM directory entry for shared DASD I hope this
helps From the z/VM 5.2
Migration Guide 4.3.1 Reserve/Release
Considerations for VSE z/VM supports virtual
reserve/release for minidisks that are not a full pack. Therefore, the
cross-system communication (also called the "lock file") volume does not have to
be defined as a full pack. MDISK statements for
all DASD you want to mount to VSE as shared (in other words, you want to use the
S operand of the IPL ADD statement) must include the V suffix on the link mode.
That is, the link mode must be MWV. If this is not done, VSE issues MSG 0I23I
for the minidisks that do not have link mode MWV on their MDISK statements.
Specifying MWV does not
result in any additional overhead because z/VM does not do a reserve/release to
any pack unless the guest asks it to. VSE only does a reserve/release to the
cross-system communication file (the "lock file") after IPL.
Note that if the
cross-system communication file (the "lock file") is shared by more than one
CPU, SHARED must be YES on the RDEVICE statement in the system configuration
file. Also, for sharing a volume concurrently between real and virtual machines,
the volume must be defined as a full-pack minidisk. Note: z/VM supports
virtual reserve/release for the virtual disks in storage function. Virtual disks
in storage are temporary FBA minidisks simulated in system storage rather than
mapped to real DASD. Therefore, a virtual disk in storage may be faster than
other minidisks because it avoids the overhead of I/O operations. VSE guests may
benefit from this function by using a virtual disk in storage instead of a
permanent minidisk to store label information areas and the cross-system
communication file (the "lock file"). The virtual disk in storage function may
be used by a guest running any supported version or release of
VSE. 0I23I
Explanation: An ADD command with the SHR option was given
for
the disk volume at the indicated address. This disk volume
is
attached to a control unit that does not support RESERVE/RELEASE
commands.
System Action: For data integrity reasons the SHR option is
not
reset. The system continues
processing.
Programmer Response: If the message occurred during
system
start-up by ASI, you may have to correct the applicable IPL proce-
dure to avoid this message in the
future.
Operator Response: Report this message to your
programmer. Gary L. Shiminsky Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act of 1996. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you. |
Title: RE: VM directory entry for shared DASD
- Re: VM directory entry for shared DASD Wakser, David
- Re: VM directory entry for shared DASD Schuh, Richard
- Re: VM directory entry for shared DASD Shiminsky, Gary - OIT
- Re: VM directory entry for shared DASD Rob van der Heij
- Re: VM directory entry for shared DASD Wakser, David
- Re: VM directory entry for shared DASD Edward M. Martin
- Re: VM directory entry for shared DASD Rob van der Heij
- Re: VM directory entry for shared DASD Tom Duerbusch
- Re: VM directory entry for shared DASD Huegel, Thomas
- Re: VM directory entry for shared DASD Edward M. Martin
- Re: VM directory entry for shared DASD Alan Altmark
