Since I am a new to the VM world and have not had a lot of hands on experience, this may come across as a dumb question.
How would one go about re-labeling VM system volumes if you are using DIRMAINT? Joseph Di Pippo Operating Systems Programmer III FRIT Computing Services Hardware Support 1-201-531-3820 Bill Munson <william.mun...@bbh.com> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 01/30/2009 10:46 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 our naming is VM1res, VM1w01, VM1pg1, VM1sp1 - VM2res,, VM2w01, etc - VM3res, VM3w01, etc for the 3 VM lpars we have Bill Munson Brown Brothers Harriman Sr. z/VM Systems Programmer 201-418-7588 President MVMUA http://www2.marist.edu/~mvmua/ "James Stracka (DHL US)" <james.stra...@dhl.com> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 01/30/2009 10:40 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 Same with me. The IBM supplied volsers never lasted for more than the few hours doing the installs. By end of day they were VMsomething. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mike Walter Sent: Friday, January 30, 2009 8: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. *************************** IMPORTANT NOTE ***************************** The opinions expressed in this message and/or any attachments are those of the author and not necessarily those of Brown Brothers Harriman & Co., its subsidiaries and affiliates BBH. There is no guarantee that this message is either private or confidential, and it may have been altered by unauthorized sources without your or our knowledge. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. BBH accepts no responsibility for loss or damage from its use, including damage from virus. *******************************************************************
