Gary, There are probably going to be a large number of replies based on everyone's own personal experiences.
Errors of Omission is rather difficult to define, which omission did you mean? If you are not present to reply, raise your hand. ;-)~ My list of "D.R. Best Practices" includes: 1) Have good, and TESTED backup and restore procedures. There are no extra points awarded for having taken backups for years, but never having tried to restore anything without a running z/VM system! Extra points WILL be awarded to writing D.R. procedures so clearly and simply that your CIO can follow to the point of IPLing the restored system. 2) Keep automatically produced daily reports to minidisk, printed to hardcopy at least weekly, showing: a) the current location of critical minidisks. The list should be quickly searchable by sorted userid and mdisk (e.g. "Where's MAINT's 02C2 disk with the "USER DIRECT" file? Or... the appropriate DIRMAINT, VM:Secure, etc. source directory disk)? Where's the backup catalog disk located? b) what's located, and where, on each real DASD (e.g. DASD VMU001 was trashed, what did we lose?). c) the allocation bitmap on each DASD. That will show the DRCT, PAGE, PARM, PERM, SPOL, or TDSK allocations when you don't have a way to look back at what once was. 3) Build a 'one-pack' IPLable system. It does not need all MAINT's disks, but should contain the utility MDISKs. All our VM DASD here is, by policy, labeled to begin with "VM". My one-pack IPLable "Virtual Machine Operating System Hipervisor Tool" DASD is labeled "VMOSHT". 4) Be sure that you can find the syntax for the 'CP DEFINE MDISK' command - and that you have tested its use from MAINT and other D.R. sysprog IDs. CP DEFINE MDISK can be your best friend in a disaster. Getting the proper authorization to get it working can be tricky. <BEWARE: CP DEFINE MDISK always provides R/W access to the defined MDISK -- use with extreme caution when testing.> 5) Ensure that your IPLable stand-alone UTILITY tapes are current. 6) TEST YOUR D.R. PROCEDURES REGULARLY. Mike Walter Hewitt Associates "Gary M. Dennis" <[email protected]> Sent by: "The IBM z/VM Operating System" <[email protected]> 12/14/2009 01:43 PM Please respond to "The IBM z/VM Operating System" <[email protected]> To [email protected] cc Subject VM Best Practices Watching ?A Christmas Story? makes me wonder if you can ?shoot your eye out? through errors of omission with a VM system. Can anyone point me to a source for z/VM ?Best Practices? that addresses low level system recovery (essentially disaster recovery). Thanks Gary Dennis Mantissa Corporation 0 ... living between the zeros... 0 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.
