Hmmm. It seems we are in agreement on that. My point was countering the
statement that MWV was necessary and sufficient for sharing with other
LPARs. It is neither necessary nor sufficient for that purpose. Making
the disk SHARED through the config file or by command fills the role for
that purpose; the V suffix in the MDISK statement fills it for virtual
machines running in the same LPAR (assuming all other requirements are
also met).

Regards, 
Richard Schuh 

 

> -----Original Message-----
> From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij
> Sent: Thursday, April 10, 2008 12:55 PM
> To: [email protected]
> Subject: Re: Ten Questions to ask a Prospective z/VM Systems 
> Programmer
> 
> On Thu, Apr 10, 2008 at 8:53 PM, Schuh, Richard 
> <[EMAIL PROTECTED]> wrote:
> 
> > You don't. Virtual Reserve/Release emulates the real reserve and 
> > release  CCWs when you have two guests in the same LPAR 
> sharing an O/S 
> > or VSE  disk. Real R/R would be of no help in that instance 
> because it 
> > applies  at the control unit level and reserves the device 
> to an LPAR 
> > or, if  running in basic mode on a pre z9 system, a 
> physical machine. 
> > Any access  from that same LPAR or machine is allowed. That is why 
> > Virtual R/R is  needed when there are multiple guests 
> sharing the same disk.
> 
> Virtual Reserve/Release is needed when you have virtual 
> machines that share a R/W disk with proper protocol. Real 
> reserve/release is necessary when you share between LPARs. 
> The combination of virtual and real reserve release is when 
> you have multiple virtual machines as well as different LPARs 
> (or systems). There is no shortcut for this.
> The other gotcha is that your mini disk must start at 
> cylinder 0 to make the real reserve/release work.
> The other interesting thing is that for example RACF does not 
> use reserve/release, but does try it to see whether the disk 
> is shared.
> Careless configuration may cause it to take a long route 
> where it should not, or may corrupt your database.
> 
> Rob
> --
> Rob van der Heij
> Velocity Software GmbH
> http://velocitysoftware.com/
> 

Reply via email to