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 >>> >>> >> >
