Here from the z/VM system I manage for IBM Belgium's BC&RS division.
USER MVSPROD xxxx 8192M 8192M G
-------------------- 1217 line(s) not displayed --------
MDISK 5902 3390 0000 10017 HWK124 MW
=================== USER MDISKMAP ==============
HWK124 3390 MVSCMC 5902 MW 000 10016 10017
MVSDEV 5902 MW 000 10016 10017
MVSGEN 5902 MW 000 10016 10017
MVSPROD 5902 MW 000 10016 10017
No overlaps signalled by DIRMAP....
And, FULLPACK DEFINES is the file in whicj you can tell DIRMAP about the
non-standard fullpack disk sizes you've got.
2010/10/4 Mike Walter <[email protected]>
> 10,017 cyls doesn't do it, either. But I don't really care - it's just
> not a problem for us.
>
> Yes, I've poked about a bit with DRM in the past. But it's way overkill
> for what we do on that system. That's more trouble to explain that it is
> worth.
>
> Thanks for the ideas, though.
>
> Mike Walter
> Hewitt Associates
> The opinions expressed herein are mine alone, not my employer's.
>
>
>
>
> "Kris Buelens" <[email protected]>
>
> Sent by: "The IBM z/VM Operating System" <[email protected]>
> 10/04/2010 03:33 PM
> Please respond to
> "The IBM z/VM Operating System" <[email protected]>
>
>
>
> To
> [email protected]
> cc
>
> Subject
> Re: How DIRMAINT Work ?
>
>
>
>
>
>
> DIRMAP (yes, not DISKMAP) will not flag fullpack minidisks as overlap
> (DISKMAP does). And, if you have non-standard disk sizes, DIRMAP can read
> a control file listing other fullpack sizes.
> I must admit that I didn't verify the 10016 number, maybe you need 10017
> (3x3339), then no *OVERLAP* anymore.
>
> As to ignore A00 and F00: it means that no single user should have such
> minidisk addresses or it won't be backed up. Ignoring user FULLPACK is
> safer (in my eyes).
>
> Without DIRMAINT (or alike) did you had a look at my DRM package: makes it
> easy to find gaps.... (etc)
>
> 2010/10/4 Mike Walter <[email protected]>
>
> > Seems nice, but, why not
> >USER -540RES- xxxxxxxx 64M 1G
> >MDISK A00 3390 00000 00001 540RES RR * Access to Allocation Bitmap
> >MDISK F00 3390 00000 10016 540RES RR * Access to full volume
> >One line less, same effort.
>
> Because those records causes an "*OVERLAP*" warning message. OK, I admit
> that I just discovered that after trying your suggestion.
>
> We we had been using A00 and F00 MDISK statements for many years. I only
> recently began adding MDISK FFFF statements to ensure that the actual GAP
> free space was clearly marked in the reports produced on a system where
> there is no directory management product installed (few DASD changes)
> installed and we manually XEDIT USER DIRECT (gasp!!!). :-)
>
> >But, then comes the day you get for example a good backup SW and you need
> to exclude all these users=volser.
> I've been using VM:Backup since early 1985. Adding DASD to VM:Secure
> requires changing the VM:Secure "DASD CONFIG" file anyway, adding IGNORE
> records for F00 and A00 is not a big deal.
>
> Mike Walter
> Hewitt Associates
> The opinions expressed herein are mine alone, not my employer's.
>
>
> "Kris Buelens" <[email protected]>
>
> Sent by: "The IBM z/VM Operating System" <[email protected]>
> 10/04/2010 01:36 PM
>
>
> Please respond to
> "The IBM z/VM Operating System" <[email protected]>
>
>
>
> To
> [email protected]
> cc
>
> Subject
> Re: How DIRMAINT Work ?
>
>
>
>
>
>
>
>
> Seems nice, but, why not
> USER -540RES- xxxxxxxx 64M 1G
> MDISK A00 3390 00000 00001 540RES RR * Access to Allocation Bitmap
> MDISK F00 3390 00000 10016 540RES RR * Access to full volume
> One line less, same effort.
>
> But, then comes the day you get for example a good backup SW and you need
> to exclude all these users=volser. That's why we used use FULLPACK, and
> only that user had FULLPACK mdisks, FULLPACK's MDISK addresses correspond
> to the rdevno.
> Other fullpack requirements where fullfilled with a LINK FULLPACK instead
> of an MDISK. The resident was defined twice: MDISK 123 and MDISK rdevaddr,
> so DIRMAINT simply had LINK FULLPACK 123 123 MW, not LINK FULLPACK rdev
> 123 MW.
> For VM:BACKUP, only FULLPACK had to be excluded (fully described in the
> document I happily send to anyone requesting it).
>
> 2010/10/4 Mike Walter <[email protected]>
>
> What if you made it a consistent practice to always allocate a minidisk at
> the highest cylinder address?
> e.g. MDISK FFFF 3390 10016 00001 540RES RR
>
> Actually, for every non-spare VM DASD at our site we make it a practice to
> create a userid in the format: -volser-
> For 540RES (the label of which we keep only long enough to complete the
> installation, after which it is immediately re-labeled), that would look
> like:
> USER -540RES- xxxxxxxx 64M 1G
> MDISK A00 3390 00000 00001 540RES RR * Access to Allocation Bitmap
> MDISK F00 3390 00000 END 540RES RR * Access to full volume
> MDISK FFFF 3390 10016 00001 540RES RR * Help out DISKMAP and DIRMAP
>
> DISKMAP then reports:
> VOLUME USERID CUU DEVTYPE START END SIZE
> 540RES -540RES- A00 3390 00000 00000 00001
>
> 1 398 398
> GAP
> MAINT 0190 3390 00399 00505 00107
>
> ...many mdisks omitted to save lots'a lines...
> someuser 01F6 3390 09978 10002 00025
>
> 10003 10015 13
> GAP
> -VMR54I- FFFF 3390 10016 10016 00001
>
>
> Being able to LINK to any VM volume in the shop can be of great value to
> sysprogs who know what they are doing with admin utility EXECs.
>
> Mike Walter
> Hewitt Associates
> The opinions expressed herein are mine alone, not my employer's.
>
> "Scott Rohling" <[email protected]>
>
> Sent by: "The IBM z/VM Operating System" <[email protected]>
> 10/04/2010 11:21 AM
>
>
>
> Please respond to
> "The IBM z/VM Operating System" <[email protected]>
>
>
>
> To
> [email protected]
> cc
>
> Subject
> Re: How DIRMAINT Work ?
>
>
>
>
>
>
>
>
>
>
> Because the DISKMAP utility is unaware of the size of the 'real' disk - so
> END is meaningless to it.
>
> I always encourage folks to not use END except under specific
> circumstances. If there is a reason other than laziness to specify END --
> then use it. Otherwise, list the number of cylinders specifically.
>
> Oh - and it can pose a danger if you rely on DISKMAP to tell you what is
> already allocated and these disks don't show up.
>
> You might want to try DIRMAINT FREE and DIRMAINT USED commands instead of
> DISKMAP. (The thread is about DIRMAINT after all ;-)
>
> Scott Rohling
>
> On Mon, Oct 4, 2010 at 10:10 AM, George Henke/NYLIC <
> [email protected]> wrote:
>
> Minidisks with the END option specified are not included in a DISKMAP when
> the command, DISKMAP USER is entered.
>
> What is the reason for this?
>
> Does this pose a danger when updating the directory directly, no pun
> intended? :-)
>
>
> Ray Waters <[email protected]>
> Sent by: The IBM z/VM Operating System <[email protected]>
> 10/04/2010 09:06 AM
>
>
>
> Please respond to
> The IBM z/VM Operating System <[email protected]>
>
>
> To
> [email protected]
> cc
>
> Subject
> Re: How DIRMAINT Work ?
>
>
>
>
>
>
>
>
>
>
>
>
> I AGREE with Scott. Sometimes it is just simpler and faster to use XEDIT
> to make multiple changes to the VM Directory. My exec performs a syntax
> check of the directory: DIRECTXA &DIRNAME DIRECT A (EDIT and then checks
> the RC. If bad RC, we go back into XEDIT to correct. Also the exec
> performs DISKMAP to check for overlaps and go back to the Directory if
> overlaps occurred. Once everything looks good, the exec takes you
> document your directory changed via: XEDIT DIRMCHNG LOG A. I have DIRMAINT
> perform the real DIRECTXA.
>
> We like having the audit and reasons for the directory updates and who
> performed the changes.
>
> Ray Waters
>
>
> From: The IBM z/VM Operating System [mailto:[email protected]] On
> Behalf Of Scott Rohling
> Sent: Friday, October 01, 2010 4:09 PM
> To: [email protected]
> Subject: Re: How DIRMAINT Work ?
>
> There are times when using DIRMAINT commands isn't practical.. for
> example - doing DASD volume relabelling. I suppose you could do a bunch
> of GET/REP commands -- or maybe DMDISK NOCLEAN and AMDISK using the same
> extents and the new volid? But I have found the best thing to do is
> update the monolithic directory with some simple plumbing and then give it
> back to DIRMAINT. I concede the loss of an audit trail, but for most
> customers that can be resolved by having a change record indicating what
> was done.
>
> Scott Rohling
> On Fri, Oct 1, 2010 at 2:50 PM, Alan Altmark <[email protected]>
> wrote:
> On Friday, 10/01/2010 at 10:24 EDT, Ray Waters
> <[email protected]> wrote:
> > We use all the ?DIRMAINT ? or ?DIRM? commands and also are able to use
> XEDIT
> > to make our major directory changes. I wrote an EXEC to ?DIRMAINT
> OFFLINE?,
> > ?DIRMAINT BACKUP?, DIRMAINT SHUTDOWN?, then ?COPY USER BACKUP B &DIRNAME
> DIRECT
> > A (OLDD ? , followed by ?XEDIT &DIRNAME DIRECT A?.
> >
> > Once my EXDIT changes are made and I ?FILE?, I ?COPY &DIRNAME DIRECT A
> USER
> > INPUT C (OLDD? to the DIRMAINT 1DF mdisk,? CP XAUTOLOG DIRMAINT?, ?EXEC
> > DIRMAINT ONLINE?.
> >
> > Anyway you get the idea. There are precautions and sleeps and performed
> by the
> > EXEC, but that is the general idea.
> Any procedure that has you editing the monolithic directory and replacing
> it as a whole means you have no audit trail (except for "directory
> replaced") and the holodeck safeties are turned off. All major directory
> changes should be made with DIRM commands. If you're making a bunch of
> changes at the same time, use DIRM NODIRECT xxxx to suppress the
> DIRECTXA, and then when you're done use DIRM DIRECT to bring all the
> changes online at the same time.
>
> Alan Altmark
>
> z/VM and Linux on System z Consultant
> IBM System Lab Services and Training
> ibm.com/systems/services/labservices
> office: 607.429.3323
> [email protected]
> IBM Endicott
>
> NOTICE:
> This e-mail is intended solely for the use of the individual to whom it is
> addressed and may contain information that is privileged, confidential or
> otherwise exempt from disclosure. If the reader of this e-mail is not the
> intended recipient or the employee or agent responsible for delivering the
> message to the intended recipient, you are hereby notified that any
> dissemination, distribution, or copying of this communication is strictly
> prohibited. If you have received this communication in error, please
> immediately notify us by replying to the original message at the listed
> email address. Thank You.
>
> The information contained in this e-mail and any accompanying documents
> may contain information that is confidential or otherwise protected from
> disclosure. If you are not the intended recipient of this message, or if
> this message has been addressed to you in error, please immediately alert
> the sender by reply e-mail and then delete this message, including any
> attachments. Any dissemination, distribution or other use of the contents
> of this message by anyone other than the intended recipient is strictly
> prohibited. All messages sent to and from this e-mail address may be
> monitored as permitted by applicable law and regulations to ensure
> compliance with our internal policies and to protect our business. E-mails
> are not secure and cannot be guaranteed to be error free as they can be
> intercepted, amended, lost or destroyed, or contain viruses. You are
> deemed to have accepted these risks if you communicate with us by e-mail.
>
>
>
> --
> Kris Buelens,
> IBM Belgium, VM customer support
>
> The information contained in this e-mail and any accompanying documents
> may contain information that is confidential or otherwise protected from
> disclosure. If you are not the intended recipient of this message, or if
> this message has been addressed to you in error, please immediately alert
> the sender by reply e-mail and then delete this message, including any
> attachments. Any dissemination, distribution or other use of the contents
> of this message by anyone other than the intended recipient is strictly
> prohibited. All messages sent to and from this e-mail address may be
> monitored as permitted by applicable law and regulations to ensure
> compliance with our internal policies and to protect our business. E-mails
> are not secure and cannot be guaranteed to be error free as they can be
> intercepted, amended, lost or destroyed, or contain viruses. You are
> deemed to have accepted these risks if you communicate with us by e-mail.
>
>
>
> --
> Kris Buelens,
> IBM Belgium, VM customer support
>
>
>
>
> The information contained in this e-mail and any accompanying documents may
> contain information that is confidential or otherwise protected from
> disclosure. If you are not the intended recipient of this message, or if
> this message has been addressed to you in error, please immediately alert
> the sender by reply e-mail and then delete this message, including any
> attachments. Any dissemination, distribution or other use of the contents of
> this message by anyone other than the intended recipient is strictly
> prohibited. All messages sent to and from this e-mail address may be
> monitored as permitted by applicable law and regulations to ensure
> compliance with our internal policies and to protect our business. E-mails
> are not secure and cannot be guaranteed to be error free as they can be
> intercepted, amended, lost or destroyed, or contain viruses. You are deemed
> to have accepted these risks if you communicate with us by e-mail.
>
--
Kris Buelens,
IBM Belgium, VM customer support
