I'll send my document with some practical directory wisdom to Valerie. - I too would not use disks defined 0 END, but set them at the real size. - keeping your minidisk off the "standard" install disks make migrations a bit easier indeed. - using LOGON BY: I wouldn't like to live without. Thanks to LOGON BY I only need to remember my own password. - LOGON BY with or without RACF are entirely different - without RACF, - you define who can use LOGON BY in the CP directory - the password LBYONLY (or alike) makes LOGON BY the only logon method - With RACF: directory definitions for LOGON BY are ignored - when you issue RDEFINE SURROGAT LOGONBY.userid the user becomes LOGON BY only - with PERMIT SURROGAT.userid CLASS(VMMDISK) ID(xxxx) you give the permissions - with PERMIT SURROGAT.userid CLASS(VMMDISK) ID(userid) the user is no longer LOGON BY only
Changing releases: the hardest part is merging the directories of the new and the old VM system. I've got some method and a few REXX execs to help with this, but not enough documentation. I used/created them on a system with RACF and DIRMAINT. Can'tt tell more in a short append like this. 2009/4/9 Mary Anne Matyaz <maryanne4...@gmail.com> > > Valerie, > I can take a couple of these questions, hopefully others will jump in on the > ones I can't answer. On the 'END' statement, I found that documented for the > diskmap utility as well, so I changed all mine to the actually cylinder > address. In the long run I found it easier to be able > to see the size of the device in user direct. (IE, oh, this linux has three > mod 27's and a mod 9). Our dasd numbering system didn't have that info, ymmv. > IE, you may know that the 1000 string, for example, is all mod 9's. Mine was > interspersed, so having the end cylinder was a quick way to find that out. > On the 191 thing, I've done both ways, the 1 cylinder 191 on the linux 200 > volume and on another volume. Either way really works fine. Only thing I > found was if you have multiple lpars, and, despite people saying 'we won't be > moving linuxes back and forth to different lpars', of course six months later > they're moving crap all around. So it was helpful to have the > 191 and the 200 on the same volume. If you have a volume full of 191's, and > you want to move the linux to a different lpar, you have to either copy the > 191 to another 191 volume or create a new one on the new lpar. > In my last shop, we had a mod 3 for non-IBM-supplied userids (ie, mine) and a > mod 3 for linux 191's. We kept that separate from the res pack for ease of > migration. But I'd be interested to hear what others are doing in hopes of > getting a consensus. > > Mary Anne > > On Thu, Apr 9, 2009 at 1:33 PM, Le Grande Valerie > <valerie.legra...@sentry.com> wrote: >> >> Hello all, >> >> I am one of the new bears trying to figure out how to use DIRMAINT to >> start defining some new users. As I have been searching the list archives >> for answers, I will start by saying I can identify with a comment made on >> this list back in February: >> "...go to a new z/VM shop that has z/VM just to support virtualized >> Linux and watch as they attempt to get DIRMAINT and RACF installed and >> configured, and then begin to use it. It isn't pretty." >> >> Haven't started on the RACF yet --- I can hardly wait! (you may all want >> to come and see the show!) >> >> Some pressing questions I have: >> >> I finally found the DIRMAP utility to map the minidisks. What I am seeing >> on my 5.4 system is that the use of the word "END" for end-of-volume and >> the resulting LENGTH seemed to get translated in my conversion from USER >> DIRECT to be 3390-01 numbers, not 3390-09 as I am using, at least on the >> report it puts out. (This is true for th $PAGE$ entry for the PAGE volume, >> the $SPOOL$ entry, and MAINT 0122 entry for the SPOOL volume, and the >> MAINT and SYSDUMP1 0123 address entries for the RES volume). Is this just >> a glitch with the report or do I need to get rid of END entries and/or >> code something else somewhere that I am missing? >> >> I would like to create some "Real" USERIDs in the style required by >> Security. I am looking for a "best practice" here. It would seem to me >> best to place "non-system user-defined stuff" (to use a technical term) >> OFF of the RES volume so it easily carries from one release to the next. I >> have noticed that the redbooks, etc. that go through creating Linux guests >> seem to put their 191 mini-disk on the volume defined for Linux use. It >> would seem to me that possibily these and definitely any admin CMS disks >> should go on what we would call on the z/OS side a "User volume" (maybe >> equal to a "Work volume" in z/VM terms?) >> What is best practice/most used for CMS disks? >> Also, can someone point me to (or give) a quick sample of what is needed >> if I use LOGONBY both in the logon TO and the BY definitions? >> >> Thanks to all of you. >> >> Also, I have no idea about carrying forward the DIRMAINT files at this >> point (let alone where they really are). How are these usually handled >> when changing releases? > -- Kris Buelens, IBM Belgium, VM customer support