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.
