Hi Kris, We are only concerned with our VSE guests which have hundreds of minidisks. Normally we just do a DIRM GET, receive the directory entry from our reader, XEDIT the file and add a minidisk or more (or delete some) and insert comments here and there. We then do a DIRM REPLACE.
All we want is to have DIRMAINT leave the entry that we XEDITed (and made pretty) alone. No changes so that next time we get it we see it the way we originally XEDITed it. Is that possible and making can you explain what DIRMAINT does on a REPLACE that causes this shuffling? Thanks, Mike -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: February 8, 2008 10:38 AM To: [email protected] Subject: Re: How comments treated by DIRMAINT I took DIRMAINT's shuffling for granted and never tried to get rid of it. The reason I think is that keeping the comments in place is far from easy: when using CMDISK for example, DIRMAINT removes user's the MDISK statement(s), and stores it/them a while in DATAMOVE's entry. When a copy is done, the new MDISK statement is move to the user's entry. I don't say all CMDISKed MDISK statements cannot be inserted at the old places with some extra REXX logic in DIRMAINT, but it wouldn't be easy to make it bulletproof. -- Kris Buelens, IBM Belgium, VM customer support 2008/2/8, Horlick, Michael <[EMAIL PROTECTED]>: > Hello Kris, > > I don't have RACF. What is the logic behind the shuffling that is done > by DIRMAINT regarding comment and MDISK statements? > > Also, is there a command to DIRMAINT that tells you what its' settings > are (for example, what the SORT_BY_DEVICE_ADDRESS is set at)? > > Thanks, > > Mike > > -----Original Message----- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > Behalf Of Kris Buelens > Sent: February 8, 2008 10:06 AM > To: [email protected] > Subject: Re: How comments treated by DIRMAINT > > If you are lucky enough to have an ESM like RACF, what means the LINK > checks are not password based, you can work the way I set things up > for my client: use the minidisk passwords as descriptive comments. > Here an extract of MAINT's entry: > MDISK 0490 3390 2362 107 VTERES RR ALL ZVM520 NOV2006 > MDISK 0493 3390 1433 167 VTERES RR ALL ZVM520 NOV2006 > MDISK 019D 3390 681 146 VTEBKP RR ALL ZVM520 NOV2006 > MDISK 049E 3390 2687 190 VTERES RR ALL ZVM520 NOV2006 > MDISK 0CF1 3390 587 80 VTERES RR > MDISK 0CF2 3390 408 80 VTEBKP > MDISK 0190 3390 399 107 VTE52R MR ALL ZVM520 AUG2007 > MDISK 0193 3390 0001 167 VTE521 MR ALL ZVM520 AUG2007 > MDISK 019E 3390 1735 190 VTE521 MR ALL FIXESCA DEC2007 > Side remark: > As one can see, we set the read password to ALL for these "general > public" minidisks. This way if we'd be forced to IPL without RACF, > people would still be able to LINK RR without password (but, even > though I still have a CP nuc without RACF on CF1, we never had to use > a CP-without-RACF in the 19 years we run with RACF) > > > > > > > We have a situation that has been annoying us for quite awhile now > with > > > regards to DIRMAINT. When we add MDISKs for a user (especially for a > VSE > > > user) we usually add comment statements just before the new MDISK. > No > > > problem, except when we later GET the directory entry the comments > are > > > in the wrong place. > > > > > -- > Kris Buelens, > IBM Belgium, VM customer support
