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:[email protected]] On Behalf Of Daniel Allen Sent: Monday, December 22, 2008 11:42 AM To: [email protected] 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:[email protected]] On Behalf Of David Logan Sent: Monday, December 22, 2008 8:33 AM To: [email protected] 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 <http://centrus.com/> W: (720) 564-3056 C: (303) 818-8222 From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Daniel Allen Sent: Monday, December 22, 2008 09:18 To: [email protected] 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:[email protected]] On Behalf Of David Logan Sent: Monday, December 22, 2008 8:02 AM To: [email protected] 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 <http://centrus.com/> W: (720) 564-3056 C: (303) 818-8222 From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Davis, Larry Sent: Monday, December 22, 2008 08:32 To: [email protected] 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:[email protected]] On Behalf Of David Logan Sent: Monday, December 22, 2008 10:14 AM To: [email protected] 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 <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. **********************************************************************
