I dare to disagree a bit: - MWV is required to get Virtual Reserve/Release, that is sharing inside z/VM. - SET SHARED ON and FULLPACK Mdisk is for Real Reserve/Release
They are different beasts: The Real R/R is a function of the dasd controller: when one system sends a Reserve, it halts the IOs from other systems. "System" was originally a CPU, now it can, be an LPAR. Multipathing since XA made it even more complex. One invented "path groups"; z/OS, z/VM etc send their unique path group id to the controller and a reserve then locks out all other path groups. Real R/R could never help to protect virtual machines from each-other (their IO come from the same path group ID), so CP has to come in and lock out IO's from other guests when one guest issued a reserve. That's Virtual R/R. And luckily: both can be combined too. I even once created a local mod to allow real R/R on non-fullpack minidisks, at a time we had the requirement to share 8 different minidisks amongst VM systems. 8 fullpacks was a bit too much in my eyes. It was an easy mod, but we had to assure not more than 1 minidisk with R/R requirement was on these packs 2010/7/28 Alan Altmark <[email protected]> > On Wednesday, 07/28/2010 at 10:03 EDT, Eginhard Jaeger > <[email protected]> wrote: > > Is that really true? When checking just now I found that the 'Planning > > and Administration' manual also says so, but I'm 99% sure (allowing > > 1% for memory deterioration) that I shared a 20 cyl. RACF database > > between two separate VM XA systems and it worked perfectly well. > > While the rest of the packs certainly shouldn't be used for any high > > activity stuff I believe we did actually use it (space was still quite > > expensive 20 years ago). > > So I suspect that the 'full pack' requirement may just come from sharing > > DASD with non-VM systems, and that it doesn't really apply to the > > RACF data base being shared between multiple VM systems only. > > But I never had to share disks for later VM releases and so don't > > know for sure .. > > Yes, it's true. CP cannot propagate a virtual Reserve/Release to the REAL > dasd if the volume contains multiple minidisks. That would cause users of > minidisk A to be affected by a reserve on minidisk B. (And reserves can > be held permanently, if desired.) > > If propagation to the real dasd isn't required then CP can simply the > reserves himself and it is ok to have multiple minidisks on the volume. > > Hence the rule for cross-system shared DASD that requires Reserve/Release: > - Full pack minidisk only > - Virtual reserve/release is enabled (MWV on the MDISK) > - The RDEVICE is configured as SHARED in SYSTEM CONFIG > > If only one guest on the VM system needs the device, then you can dedicate > it, but you don't want to do that with RACF since you may want to be > testing something with RACMAINT while RACFVM is running, or you may want > multiple RACFVMs. > > Since it's all just ones and zeroes, it is theoretically possible to > invent a "1-END" minidisk that would cause a full-pack reserve to flow, > but we're talking about RACF, a highly trusted component of the system, so > I'm not really worried about something hacking in and doing violence to > the volser. "Acceptable risk." > > What I *am* looking at is finding a way to let RACF detect non-fullpack > configurations when it is configured for cross-system sharing. The > default minidisk configurations work ok because they are defined MR, not > MWV. The lack of the "V" causes RACF's attempts to ENQ (reserve) the > volume to fail. That triggers RACF to cache database content for > performance instead of doing I/O all the time, KNOWING that there is no > sharing. Changing to MWV is sufficient for adding extra RACF servers or > z/OS guests on the same system, but not for cross-LPAR sharing. > Unfortunately, RACF does not today require you to declare your intent vis > a vis database sharing and so cannot enforce any particular configuration. > > Alan Altmark > z/VM Development > IBM Endicott > -- Kris Buelens, IBM Belgium, VM customer support
