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 <mike.wal...@hewitt.com> > > 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" <scott.rohl...@gmail.com>* > > Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> > > 10/04/2010 11:21 AM > Please respond to > "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> > > > To > IBMVM@LISTSERV.UARK.EDU > 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 <* > george_he...@newyorklife.com* <george_he...@newyorklife.com>> 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 <**ray.wat...@opensolutions.com*<ray.wat...@opensolutions.com> > *>* > Sent by: The IBM z/VM Operating System > <*ib...@listserv.uark.edu*<IBMVM@LISTSERV.UARK.EDU> > > > > 10/04/2010 09:06 AM > > > Please respond to > The IBM z/VM Operating System > <*ib...@listserv.uark.edu*<IBMVM@LISTSERV.UARK.EDU> > > > > To > *ib...@listserv.uark.edu* <IBMVM@LISTSERV.UARK.EDU> > 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:*ib...@listserv.uark.edu*<IBMVM@LISTSERV.UARK.EDU>] > *On Behalf Of *Scott Rohling* > Sent:* Friday, October 01, 2010 4:09 PM* > To:* *ib...@listserv.uark.edu* <IBMVM@LISTSERV.UARK.EDU>* > 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 > <*alan_altm...@us.ibm.com*<alan_altm...@us.ibm.com>> > wrote: > On Friday, 10/01/2010 at 10:24 EDT, Ray Waters > <*ray.wat...@opensolutions.com* <ray.wat...@opensolutions.com>> 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*<http://ibm.com/systems/services/labservices> > office: 607.429.3323* > **alan_altm...@us.ibm.com* <alan_altm...@us.ibm.com> > 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
