There used to be a real nice 'how to' appendix in DIRMAINT book but I just can't find it now. I'll just comment on a thing or two. First to setup a 'real' user on something other than a 540xxx disk. What you need to do is to update the EXTENT CONTROL file to add a new USER group/pool on a volume other than 540xxx. The best way to do this is to use DIRM SEND .. edit the file DIRM FILE and DIRM RLDEXTN. Then when you create MDISKs for the new user id's you can put them in the new user group.
As for LOGONBY, you mentioned RACF, so don't worry about LOGONBY in DIRMAINT, let that control be with RACF. -----Original Message----- From: The IBM z/VM Operating System [mailto:[email protected]]on Behalf Of Mary Anne Matyaz Sent: Thursday, April 09, 2009 1:32 PM To: [email protected] Subject: Re: USER MDISK and DIRMAINT Question 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?
