On Saturday, 05/22/2010 at 02:36 EDT, TaeMin Baek <[email protected]> wrote: > When one guest OS/390 access to a certain dataset, > 1) z/VM CP control the DASD and set it reserved > 2) if other OS/390 guest try to access different dataset in same DASD, it must > wait and CP continue to check until DASD is released. > > Is the above logic of shaing DASD is right? > If it is right, i think GRS is useless now and it can give more workload to CP.
Not quite, no. Confirming what Kris said, OS/390 issues a RESERVE command to the virtual DASD and CP remembers it. Since you have a fullpack minidisk, if you also haved the dasd volume defined as SHARED on an RDEVICE statement in SYSTEM CONFIG, then CP will also issue a real RESERVE so that it can be shared with other LPARs. If you aren't sharing the dasd volume with other LPARs, you can leave it as unshared. Further, it is *OS/390* that keeps checking, not CP. That constant checking is what will drive up the CPU consumption, as CP has to keep saying rejecting the I/O. > Today we tried to change sharing DASD method from with using Virtual > Reseve/Release to without using Virtual Reseve/Release. > What i mean is that i don't use MDISK with 'V' option. Only define MDISK with > 'MW' option. The question is really "Why is OS/390 issuing hw reserves?" Because something (e.g. JES) is issuing RESERVEs or ISGENQ RESERVEVOLUME=YES (I don't know if ISGENQ exists in OS/390). > I want to let GRS in OS/390 to control dataset level sharing like in Native > LPAR mode. > I guess it might reduce the CP workload relate to reserve/release DASD. GRS gives you the ability to control whether or not RESERVE will cause a real reserve to be issued to the hw. You can convert a RESERVE to a global ENQ by placing the dataset and queue name in the RESERVE conversion RNL. You may have to turn on the ENQ/DEQ/RESERVE monitor to see what's happening and get all the correct names. When you do this, then it will no longer be necesssary for OS/390 to poll the device to see if the hw reserve is still there. When one system issues DEQ for the volume, the other systems will be notified via GRS and one of them will race. Note that you should turn off the hw reserve ONLY if the dataset or volume is NOT being shared outside of the GRS complex. > But the problem is JES failed to start because it cannot access the volume > containg checkpoint dataset. > The message said the volume containing checkpoint dataset is not shared. Without the "V", the RESERVE macro issued by JES fails. Caveat: I am not a z/OS or GRS expert. Alan Altmark z/VM Development IBM Endicott
