Since I may be taking over some VM duties soon and I haven't worked on it since 1984 (yeah, I know!), I am curious if the second question from Jonathan can be answered? Seems like a waste if multiple VM systems can't share r/o res volumes. Thx.
Guy Gardoit z/OS Systems Programming On Fri, Jan 30, 2009 at 10:26 AM, Quay, Jonathan (IHG) < jonathan.q...@ihg.com> wrote: > Which leads to a couple of questions. First, when did IBM start > supporting RES packs with volsers other than the standard ones as > delivered? I seem to remember warnings about not changing them, but may > have missed when that became ok. *Second, if one's intent is to run > nearly identical "cloned" VM images across some number of LPARS on some > number of CECs, would there be a simple way to do this from one Master > read-only RES pack containing various CPLOAD modules and system > configuration files, sort of like our z/OS brethren do?* > > -----Original Message----- > From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On > Behalf Of Alan Altmark > Sent: Friday, January 30, 2009 10:06 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Re-labeling CP-Owned volumes on a live system > > On Friday, 01/30/2009 at 09:29 EST, Kris Buelens > <kris.buel...@gmail.com> > wrote: > > I really prefer unique volsers. > > I know I ranted on this issue recently, but it needs to be more than a > 'preference'. z/VM is designed to run in an environment with UNIQUE > volsers (PAV aliases are not of concern since CP understands the > relationship). If you don't have unique volsers, then YOU are > responsible > for system and data integrity. > > This means you need to understand the implications of a copy or restore > operation (whether DDR or FLASHCOPY) and of giving a guest access to > real > cylinder zero. You must take precautions to ensure that such volumes > are > never seen or felt by CP except at your explicit discretion. Always > assume that your system will restart at the worst possible moment or > that > there may be a coup d'machine and someone else may take charge of the > I/O > subsystem. (DR, anyone?) And, of course, we know that Other People make > > mistakes! :-) > > Alan Altmark > z/VM Development > IBM Endicott >
