Very True Tom. I was just giving a situation with one second level guest. I realize, some shops cannot control how many duplicated volsers and who is creating these duplicates (such as a school). My situation is a controlled environment, where only Tech Support does this kind of stuff, and we communicate well.
Ray From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Huegel Sent: Friday, August 27, 2010 8:22 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Duplicate VOLID's OK Ray, that is the best tip yet. But there are flaws you are assuming that you are the one in control. Picture a situation where there is a pool of DASD that is available for 'anyone' to use, for anything they want to use them for. They could have z/VM system volumes, z/OS, z/LINUX, z/VSE, or just application data. At some point they all get reinitialized but not until the user is done which could be weeks. Also consider that there are several z/VM 'production' systems in different LPARS or CEC's They can't all be at the lowest address.. Some others have suggested labeling schemes ie VMrdev..... As for labeling the volumes with the rdev ie VM1234, yes I use that scheme when returning the packs to the user pool. Labeling the packs as VMrdev doesn't address the problem, I am not interested tracking those volid's I only care about xxxRES, xxxWK1, xxxWK2, etc.... On Fri, Aug 27, 2010 at 7:47 AM, Ray Waters <ray.wat...@opensolutions.com<mailto:ray.wat...@opensolutions.com>> wrote: I often bring up a second level VM system with the same volsers: 540RES, 540WK1, 540WK2, ... I always use a higher address for the duplicated volume when I DDR copy. In other words if 540WK1 is say 209, the DDR copied volume would be something like 847. This way, if 1st level VM happens to go down, before I finish my testing, it should find the lower addressed volumes (production volumes) and use these to IPL with. VM will start looking at each address with lower addresses prior to higher addresses. The only way this would fail, would be if VM fails on the read of the production VM volume or volumes. Once testing is completed, I ICKDSF these copied volumes back to their original state/volid. Been doing this for 30 years and haven't got burned yet, yet, yet. Ray From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>] On Behalf Of Scott Rohling Sent: Thursday, August 26, 2010 9:45 PM To: IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU> Subject: Re: Duplicate VOLID's Would definitely agree an rdev specification on the SLOT def would be very useful. I just recently built a 2nd level guest and neglected to relabel the volumes before they IPL'd the 1st level system ... ugly. Wouldn't have happened if the real address was specified... good idea! Scott Rohling On Thu, Aug 26, 2010 at 7:58 PM, Tom Huegel <tehue...@gmail.com<mailto:tehue...@gmail.com>> wrote: So I guess there is no way to absolutly protect z/VM from using the wrong pack at IPL.. Maybe a requirement? In SYSTEM CONFIG allow optional rdev on the SLOT deffinations. comments? On Thu, Aug 26, 2010 at 5:15 PM, Schuh, Richard <rsc...@visa.com<mailto:rsc...@visa.com>> wrote: DIRMAINT is just a directory manager. It is similar to the directory manager component of VM:Secure. DIRMAINT does have the capability to do mass updates of the directory. VM:Secure does not. I have my own form of mass updater. I create code to perform the update of a generic single user and temporarily EXECLOAD it as PROFILE XEDIT. Then I run a pipe that looks something like this: 'PIPE < id list a | spec /vmsecure edit/ 1 w1 nw | cms | > log file a' It usually runs quickly because our directory has fewer than 2000 userids in it. It might not be acceptable on a system with 10000+ userids. Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>] On Behalf Of Scott Rohling Sent: Thursday, August 26, 2010 4:56 PM To: IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU> Subject: Re: Duplicate VOLID's Hmm.. RACF isn't really related as it's protecting minidisks on z/VM, at least - and doesn't care about volsers the mindisks are on. The process for DIRMAINT is probably similar to the things that need doing on VM:Secure to do the directory changes: - Make a 'monolithic' copy of the directory and run a PIPE to change all volsers.. then initialize DIRMAINT using the new directory (USER INPUT) - Put the directory online (DIRM DIRECT) - Change EXTENT CONTROL similarly and do a DIRM RLDE I'm in favor of labels using the rdev - unless you really have frequent changes of DASD - to me, the benefits outweigh the occassional need to update the directory. YMMV, as this thread indicates. Scott Rohling On Thu, Aug 26, 2010 at 3:33 PM, Schuh, Richard <rsc...@visa.com<mailto:rsc...@visa.com>> wrote: That is absolutely the wrong thing to do. I am now suffering because someone else did that to dasd that is EMFFd to 3 LPARS. (It was all ZLccuu). It requires meticulous record keeping and is very error prone. I did wipe out a disk needed by one system because the records I received were not complete Fortunately, it was a disk that was to be used by a new system and had not been updated; it was easy to restore. Also, it is a huge headache if you ever replace your DASD. I don't know about RACF, but there is no mechanism built into VM:Secure for easily doing a mass update of volsers ( I know, you can change the volser with one command - if it is a VM:Secure .controlled disk and nobody is linked to it. The latter is hard to achieve around here.) Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>] On Behalf Of Michael MacIsaac Sent: Thursday, August 26, 2010 10:55 AM To: IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU> Subject: Re: Duplicate VOLID's >I do know what addresses my system disks are on, Ah! - an argument for the convention of using the RDEV as the last four characters of the volser :)) "Mike MacIsaac" <mike...@us.ibm.com<mailto:mike...@us.ibm.com>> (845) 433-7061 ________________________________ NOTICE: This e-mail is intended solely for the use of the individual to whom it is addressed and may contain information that is privileged, confidential or otherwise exempt from disclosure. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the original message at the listed email address. Thank You. ________________________________ NOTICE: This e-mail is intended solely for the use of the individual to whom it is addressed and may contain information that is privileged, confidential or otherwise exempt from disclosure. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the original message at the listed email address. Thank You.
