On Wednesday, 07/28/2010 at 10:03 EDT, Eginhard Jaeger <e.jae...@ch.inter.net> 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
