Hmmm... I distinctly remember warnings not to do this in the installation docs, because I wanted to have unique res pack volsers and that made me go down another path. This was ESA 2.2 or later.
________________________________ From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mike Walter Sent: Friday, January 30, 2009 10:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Re-labeling CP-Owned volumes on a live system When? Well... I've been installing VM since VM/370 Release 5 and there was never a requirement to use ONLY the IBM supplied volsers for anything. When I arrived at Hewitt Associates to install VM in 1984, I was told in no uncertain terms that ALL VM DASD volsers MUST be labeled beginning with "VM", as in with VMxxxx. Over time, they have relented, permitting them to begin with just "V". You just need to take extra steps during the installation process, steps which are not documented as part of that installation process. It's all part of the learning curve, and good for your career . If it was too easy, everyone would do it! ;-) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Quay, Jonathan (IHG)" <jonathan.q...@ihg.com> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 01/30/2009 09:26 AM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Re-labeling CP-Owned volumes on a live system 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 ________________________________ 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.