Yes -- that's a good strategy too ... I usually pay attention to the addresses - but this was our test/play system, so didn't give it the careful thought I normally would. Higher addresses can also prevent an issue with duplicates....
Scott Rohling On Fri, Aug 27, 2010 at 6:47 AM, Ray Waters <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:ib...@listserv.uark.edu] *On > Behalf Of *Scott Rohling > *Sent:* Thursday, August 26, 2010 9:45 PM > > *To:* 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> 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> 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:ib...@listserv.uark.edu] *On > Behalf Of *Scott Rohling > *Sent:* Thursday, August 26, 2010 4:56 PM > > > *To:* 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> 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:ib...@listserv.uark.edu] *On > Behalf Of *Michael MacIsaac > *Sent:* Thursday, August 26, 2010 10:55 AM > > > *To:* 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> (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. >
