If the z/OS machines are all running as guests of the same VM system, there are no hardware reserves that are needed or would do any good. All that is needed is the Virtual R/R. The reason for this is that any guest can update a disk that is reserved by any other guest of that system if you are trying to use the hardware R/R. The device is reserved to the LPAR that issued the RESERVE, not to the user or job that issued it. Thus the need for the virtual R/R to keep the guests from clashing.
VM does not try to handle hardware R/R. That is the province of the guests using the device. If you are trying to have a VM guest share a real DASD device with another z/OS running in a different LPAR, you need to use the real R/R which requires that the devices be defined as SHARED. Without the SHARED attribute, a RESERVE CCW will not be honored by VM. My memory is failing me - I don't remember whether the CCW will simply be ignored or whether an error will be reflected to the guest. I would suspect that it is the latter because that is what hardware that does not support R/R would do, it would reflect a UC with Command Reject. To further complicate matters, it is possible to have both types of sharing at the same time. To do that, you need both the SHARED parameter in the device definition or via the SET SHARED command and you must have the V suffix in the mode specification of the MDISK statement in the device owner's directory entry. Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of David Logan > Sent: Monday, December 22, 2008 4:19 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: CTC connections between VMs > > OK, thanks! I will work my way through this. Does this assume > we are using GRS to convert RESERVEs into GRS locks, or are > you letting VM handle hardware RESERVEs? (Or does this > example work with either?) > > David Logan > Manager of Product Development, Pitney Bowes Business Insight > http://centrus.com > W: (720) 564-3056 > C: (303) 818-8222 > > > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Mike Walter > Sent: Monday, December 22, 2008 10:50 > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: CTC connections between VMs > > David, > > Here are a couple cut/paste examples of DASD sharing used by > three z/OS > 1.8 guests on a z/VM 5.4 system running in a virtual sysplex > of their own. > Userids have been changed to protect the innocent. > > Your mileage may vary. No expressed of implied warranties. > Yada, yada, yada... > > Mike Walter > Hewitt Associates > Any opinions expressed herein are mine alone and do not > necessarily represent the opinions or policies of Hewitt Associates. > > > ---<snip>--- > PROFILE ZOSPROF > ACCOUNT OVERHEAD 93S0 > MACH ESA 64 > IPL CMS PARM AUTOCR > OPTION CFUSER > OPTION COMSRV > OPTION DEVINFO > OPTION DEVMAINT > *OPTION DIAG98 !! NOT FOR z/OS vm's - causes OSA and TCPIP errors !! > OPTION MAINTCCW > OPTION MAXCONN 65535 > OPTION MAXVMCFI 2147483647 > OPTION MIH > OPTION NOMDCFS > OPTION QUICKDSP > OPTION RMCHINFO > OPTION STGEXEMPT > OPTION SVC76VM > OPTION TODENABLE > OPTION SVMSTAT > *OPTION V=F > *OPTION V=R > *XCONFIG ACCESSLIST ALSIZE alecount > *XCONFIG ADDRSPACE MAXNUMBER nnnnn TOTSIZE nnnnG > SHARE|NOSHARE *XSTORE ALL|size LINK MAINT 190 190 RR LINK > MAINT 19D 19D RR LINK MAINT 19E 19E RR SPECIAL 701 3270 > SPECIAL 702 3270 ... > SPECIAL 71F 3270 > * > SPECIAL 0100 MSGPROC CF1 > SPECIAL 0200 MSGPROC CF2 > * > LINK STEDASD 6C00 6C00 MW > LINK STEDASD 6C01 6C01 MW > LINK STEDASD 6C02 6C02 MW > LINK STEDASD 6C03 6C03 MW > LINK STEDASD 6C04 6C04 MW > LINK STEDASD 6C05 6C05 MW > ... > ---<snip>--- > > > > The key to the following is the use of 'DEVNO'. That allows > read device addresses to be shared and the z/OS sysprogs to > re-label DASD volsers without the z/VM sysprog having to > change VM directory entries. > > ---<snip>--- > USER ZOSDASD NOLOG > MDISK 6C00 3390 DEVNO 6C00 RV READ WRITE MULT > * The next two are only present to reduce the chance of > anyone from using these addresses *MDISK 6C01 3390 DEVNO 6C01 > RV READ WRITE MULT $SPLX3 wkralleg *MDISK 6C02 3390 DEVNO > 6C02 RV READ WRITE MULT $SPLX3 wrkalleg MDISK 6C03 3390 > DEVNO 6C03 RV READ WRITE MULT MDISK 6C04 3390 DEVNO 6C04 RV > READ WRITE MULT MDISK 6C05 3390 DEVNO 6C05 RV READ WRITE MULT ... > ---<snip>--- > > > > ---<snip>--- > > USER ZOS1 xxxxxxxx 4G 16E GB 64 > * See above: PROFILE ZOSPROF for common ZOSn statements > INCLUDE ZOSPROF SHARE RELATIVE 250 > ACCOUNT ZOS1 93S0 > * DOMAIN = regs, APDED=cards; VM can't share DOM in same APDED > CRYPTO DOMAIN 1 APDEDICATED 2 3 CSU * > CPU 0 NOVEC BASE > CPU 1 NOVEC > CPU 2 NOVEC > CPU 3 NOVEC > CPU 4 NOVEC > CPU 5 NOVEC > CPU 6 NOVEC > CPU 7 NOVEC > CPU 8 NOVEC > CPU 9 NOVEC > CPU A NOVEC > CPU B NOVEC > CPU C NOVEC > CPU D NOVEC > CPU E NOVEC > CPU F NOVEC > ... > * HyperSockets > DEDICATE vdev rdev > DEDICATE vdev rdev > DEDICATE vdev rdev > * Internal Gigabit OSA > DEDICATE vdev rdev > DEDICATE vdev rdev > DEDICATE vdev rdev > CONSOLE 700 3270 C OPERATOR > SPOOL 00C 3505 > SPOOL 00D 3525 > SPOOL 00E 3211 > MDISK 0191 3390 begcyl numcyls volser RR readpw writemw multpw > ---<snip>--- > > > > > > > "Davis, Larry" <larry.davis...@nielsen.com> > > Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> > 12/22/2008 11:12 AM > Please respond to > "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> > > > > To > IBMVM@LISTSERV.UARK.EDU > cc > > Subject > Re: CTC connections between VMs > > > > > > > The method I use to share DASD with guests is to have a > Single ID that owns the DASD like "ZOSDASD" and all the MDISK > statements in this directory would have the MWV statement to > allow for Reserve Release processing > > Then each of the z/OS systems would have LINK statements to > the ZOSDASD ID using just MW as the link method. > > If you really want to simplify things and you add and remove > DASD every so often, setup the LINK statements in a Directory > Profile and include that profile in each of the z/OS's directories. > > I hope this helps > > Larry Davis > > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Daniel Allen > Sent: Monday, December 22, 2008 11:42 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: CTC connections between VMs > > Prior to z/OS 1.8, z/OS systems could co-exist with N-3 (ie. > z/OS 1.4, 1.5, 1.6 and 1.7). > > At the z/OS 1.8 and higher, z/OS systems can co-exist with > N-2 (ie. (z/OS 1.6, 1.7 and 1.8),(z/OS 1.7, 1.8 and 1.9)). > > It is a question of toleration PTFs to allow z/OS systems to > co-exist in a sysplex. If you run stand-alone z/OS systems, > there is no problem. > > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of David Logan > Sent: Monday, December 22, 2008 8:33 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: CTC connections between VMs > > So the GRS communication changed between 1.5 and 1.8, making > them incompatible? If so, I?m fine with that. > > David Logan > Manager of Product Development, Pitney Bowes Business Insight > http://centrus.com > W: (720) 564-3056 > C: (303) 818-8222 > > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Daniel Allen > Sent: Monday, December 22, 2008 09:18 > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: CTC connections between VMs > > z/OS 1.4 and 1.5 can co-exist together and z/OS 1.8 and 1.9 > can co-exist together. > > All four z/OS systems should not co-exist in a sysplex together. > > You could simulate two sysplexes under z/VM. > > > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of David Logan > Sent: Monday, December 22, 2008 8:02 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: CTC connections between VMs Well, I was thinking > simulate a sysplex, but let me just be clear about my thought process. > > I have a z/OS 1.4, a z/OS 1.5, a z/OS 1.8 and a z/OS 1.9 > partition running right now. > > I want to share most of my DASD amongst the operating > systems, so things like data and software builds can be > immediately used on all platforms without having to > copy/build to each one individually. > > It appears that VM will share DASD easily enough, but it > appears that it uses RESERVE to do so > > Thus, I assume I would want to set up virtual CTCs > specifically so I can set up a GRS ring to convert reserves > into GRS locks. I?m not really looking for the complete > connectivity that one would normally expect in a sysplex. > > David Logan > Manager of Product Development, Pitney Bowes Business Insight > http://centrus.com > W: (720) 564-3056 > C: (303) 818-8222 > > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Davis, Larry > Sent: Monday, December 22, 2008 08:32 > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: CTC connections between VMs > > Are you trying to simulate a sysplex under the control of VM > or are you trying to interconnect several MVS and VM LPAR's together? > > Larry Davis > > > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of David Logan > Sent: Monday, December 22, 2008 10:14 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: CTC connections between VMs > Do we need an actual 3088 to define CTC connections between > VMs, or does VM provide virtual connectivity we can use? > > Or to ask a question more related to my need: Can I set up a > GRS ring amongst various z/OS operating systems on my z/VM > without a physical CTC? > > Thanks! > > David Logan > Manager of Product Development, Pitney Bowes Business Insight > http://centrus.com > W: (720) 564-3056 > C: (303) 818-8222 > > ********************************************************************** > This email and any files transmitted with it are confidential > and intended solely for the use of the individual or entity > to whom they are addressed. > Any unauthorized review, use, disclosure or distribution is > prohibited. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of > the original message. > ********************************************************************** > > > > > > The information contained in this e-mail and any accompanying > documents may contain information that is confidential or > otherwise protected from disclosure. If you are not the > intended recipient of this message, or if this message has > been addressed to you in error, please immediately alert the > sender by reply e-mail and then delete this message, > including any attachments. Any dissemination, distribution or > other use of the contents of this message by anyone other > than the intended recipient is strictly prohibited. All > messages sent to and from this e-mail address may be > monitored as permitted by applicable law and regulations to > ensure compliance with our internal policies and to protect > our business. E-mails are not secure and cannot be guaranteed > to be error free as they can be intercepted, amended, lost or > destroyed, or contain viruses. You are deemed to have > accepted these risks if you communicate with us by e-mail. >
