We've got MAINT B91 as backup of MAINT 191 since the VM/SP days. Our DIRBKP EXEC keep the last 9 levels of the CP directory there, as well as SYSTEM CONFIG; the result of a QUERY DASD and Q ALLOC. DIRBKP does not only maintain these backups but also performs some checks each night such as: is MDISK MAINT 298 (i.e. VTAM) still in the directory. Additionally, the 9 copies of the directory & co are also copied to a central SFS: so when a system is down due to disk errors, we know what is lost (touching wood: didn't need this for more than 10 years).
2008/3/10, Mike Walter <[EMAIL PROTECTED]>: > Maybe it would be better to keep the USER DIRECT file (or whatever you're > using as the source directory) off the 191 disk altogether, placing it on > a separate disk, and at "known address"? > > "Known address" could be defined in two parts: > > 1) Perhaps at cylinder 1 of a particular volser that you know and love > (and can remember in a crisis)? > 2) A new MAINT MDISK, maybe "5DD" (following VMSES/E's convention of the > '5' looking a bit like an 'S' when one squints ones eyes - the 5DD reminds > one of the SDD or 'S'ource 'D'irectory 'D'isk )? > > Or, following the "SYSTEM CONFIG" CF1/CF2/CF3 disk standards, a paranoid > sysprog could set up SD1, and SD2 disks. Where the live directory is on > the SD1 directory (at a "known extent on a "known" volume), always make a > backup copy to the SD2 disk (at a "known extent on a "known" volume) > before making any changes. That way if anything goes wrong you can always > go back one generation without needing to mount a tape. It vastly reduces > the chances of formatting *both* disks. It depends on your level of > paranoia. > > By placing it on a disk other than 191 one must be very sure to never copy > or save it to the 191 disk by accident or on purpose (just for a test, of > course) because then you have the "opportunity" to figure out which is the > real "USER DIRECT", or worse - which has some of the real entries and > which has the rest of the real entries. A good "PROFILE EXEC" could > easily check for such duplicate errors. > > Mike Walter > Hewitt Associates > Any opinions expressed herein are mine alone and do not necessarily > represent the opinions or policies of Hewitt Associates. -- Kris Buelens, IBM Belgium, VM customer support
