We do this: * * CMS 23 disks at 1st Level * MDISK 2390 3390 2184 107 VMRESB RR ALL CMS23A 190 MDISK B390 3390 0282 107 VMRESB RR ALL CMS23B 190 MDISK 2393 3390 1664 200 VMRESA RR ALL CMS23 193 MDISK 239D 3390 1864 300 VMRESA RR ALL CMS23 19D MDISK 239E 3390 1007 250 VMRESA RR ALL CMS23 19E MDISK B39E 3390 3139 200 VMRESB RR ALL CMS23B 19E
Of course we use the CMS IPLER. -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Friday, February 08, 2008 3:32 PM To: [email protected] Subject: Re: How comments treated by DIRMAINT These block comments don't solve the problems of deleted minidisks. (I reverted to that too when we started with DIRMAINT). Nor do they help when working like me with two alternating runtime minidisks. Eg MAINT 190 and 490 have two different CMS levels. When switching levels (forward or backout), I swap the addresses in the directory. I don't use DDR, address swapping can often be done in flight: old users go one, new users get the new stuff, impossible with DDR (for CSM I have different saved segments). With comments on the MDISK card itself, it also always clear which is which, even if a phone call interrupts your thoughts in the XEDIT session used to swap the addresses (did or didn't I swap this one already? In the day preceeding this trick, I often encountered this in real life and QQUIT was often the only safe way to go on). Standard example: MDISK 0490 3390 2362 107 VTERES RR ALL WMAINT MMAINT MDISK 0493 3390 1433 167 VTERES RR ALL WMAINT MMAINT MDISK 019D 3390 681 146 VTEBKP RR ALL WMAINT MMAINT MDISK 049E 3390 2687 190 VTERES RR ALL WMAINT MMAINT MDISK 0190 3390 399 107 VTE52R MR ALL WMAINT MMAINT MDISK 0193 3390 0001 167 VTE521 MR ALL WMAINT MMAINT MDISK 019E 3390 1735 190 VTE521 MR ALL WMAINT MMAINT When looking at this, you don't know which is the newest copy (the volsers are different in this case, and might help here, but this is from my test system, on other systems these CMS minidisks might be all located on the same volser, a matter of chance/malchance). 2008/2/8, Dale R. Smith <[EMAIL PROTECTED]>: > What I have done for this situation is add a block comment to the > directory entry before the MDISKs that describes what each MDISK is > used > > for. The comments are not directly associated with a MDISK, so you > have > > to maintain the comments and MDISKs separately, (you kinda have to do > tha t now). The advantage of using a comment block is that the > descriptions ar e > all in one place and you don't have to worry about DIRMAINT, (or any othe > r > directory manager), messing with them. Here is an example from one of ou > r > DB2/VM userids: > > *---------------------------------------------------------------------* > * CMS Minidisk Layout * > * 191 Work Disk and Profile Exec * > * 193 DB2/VM Service Disk * > * 195 DB2/VM Production Disk * > * 200 Directory * > * 201 Log Disk 1 * > * 202-203 Pool 1 - System Catalogs * > * 204-205 Pool 2 - Internals * > * 206 Pool 3 - QMF and DBEDIT * > * 207 Pool 4 - PUBLIC.EXPLAIN * > * 208-211 Pool -5 - Non-Recoverable * > * 212-219 Pool 6 - Recoverable * > * 220-221 Pool -5 - Non-Recoverable * > * 222 Pool 3 - QMF and DBEDIT * > * 223-224 Pool -5 - Non-Recoverable * > * 225-226 Pool 6 - Recoverable * > * 227 Log Disk 2 * > * 228 Pool 3 - QMF AND DBEDIT * > * 229 Pool 6 - Recoverable * > * 230 Pool 6 - Recoverable * > * 231-234 Pool 2 - Internals * > *--------------------------------------------------------------------- > * > > > Of course, your comments for VSE MDISKs would be a lot different! > :-)> Just put in what makes sense to you. Add a new comment line when > you add > > a new disk, delete a line when delete a disk. > > -- > Dale R. Smith > > "It's just a simple matter of programming." > - Any boss who has never written a program > > On Fri, 8 Feb 2008 11:12:34 -0500, Horlick, Michael > <[EMAIL PROTECTED]> wrote: > > >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 > -- Kris Buelens, IBM Belgium, VM customer support -------------------------------------------------------- This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. --------------------------------------------------------
