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 < [email protected]> 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? >
