Having been in the same situation, my advice is that it is better to be safe than sorry. We had one individual who, on more than one occasion, formatted MVS volumes for use by TPF test systems. Needles to say, the MVS folks were not happy. I took the power away from him on two fronts when I was given responsibility for VM - 1. I took Class B away from him, and 2. I put all MVS disks that were not intentionally shared in the Not_Accepted list.
The DASD Storage Management group, who controlled the world when it came to DASD surface acreage, thought it was a good idea to interleave the devices, giving VM the even numbers and MVS the odd. The MVS folks were trying to time the remote (2000 miles) replication of their DASD during what turned out to be a heavy period for VM. Our pleas to segregate the VM and MVS DASD finally struck home. They were not expecting VM to interfere with them. The outcome was not pretty - there were timeouts, and even failures, of the replication process due to the load that VM was putting on the channels. For me, the best practices are 1. Segregate the dasd, 2. Only have the disks that are intended for use by VM online, and 3. only give the power to ATTACH and DETACH to responsible parties who have a need for doing so. Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Karl Huf > Sent: Tuesday, April 05, 2011 3:44 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: z/VM & z/OS sharing same DASD > > I could have sworn I had seen something about this in a > presentation regarding "best practices" for configuring z/OS > & z/VM LPAR's that share the same DASD subsystems but now > that I need it, no joy. > > We have 2 (z10) CEC's, each with z/VM and z/OS LPAR's > attached via FICON Directors to a pair of DS8700's. As > currently configured all of the DASD is defined on common > LCU's and all of the DASD is online to all systems. > This makes me nervous but perhaps my fears are unfounded? My > gut tells me that a better configuration would be having the > VM DASD segregated onto dedicated LCU's and the rest of the > MVS DASD on their own LCU's - and that the respective devices > not be online to the "foreign" OS's. Due to other recent > discoveries we have some DASD reconfiguration work ahead of > us anyway and, if it's worthwhile, I'd like to pile on with > getting the VM DASD to be isolated as part of that work - but > at the moment I can't quantify to those that would do the work why. > > Are there good reasons or am I making mountains where there > are no molehills? TIA. > > > ______________________________________________________________ > _________________ > Karl S Huf | Senior Vice President | World Wide Technology > 840 S Canal, Chicago, IL, 60607 | phone (312)630-6287 | k...@ntrs.com > Please visit northerntrust.com > CONFIDENTIALITY NOTICE: This communication is confidential, may be > privileged and is meant only for the intended recipient. If > you are not > the intended recipient, please notify the sender ASAP and delete this > message from your system. > > IRS CIRCULAR 230 NOTICE: To the extent that this message or > any attachment > concerns tax matters, it is not intended to be used and > cannot be used by > a taxpayer for the purpose of avoiding penalties that may be > imposed by > law. For more information about this notice, see > http://www.northerntrust.com/circular230 > > P Please consider the environment before printing this e-mail. >
