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
