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 <[email protected]>
>
> 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?
>
--
Kris Buelens,
IBM Belgium, VM customer support
