I think the most important action--but not necessarily the first--is V XCF OFF. That should stop ongoing I/O in as synchronized a manner as possible across all applications.
$PJES2 will most certainly never complete, but it will prevent any new tasks from starting. I would NOT do a TERM because you lose all control at that point. As for CICS and DB2, we've had system crashes that they recover from quite robustly--as long as CF structures remain intact. You didn't mention data sharing or the location of CFs. Losing a z/OS system AND its supporting CF is a recipe for extended recovery. The key I believe is to issue V XCF OFF before any devices start to go casters up. So I wouldn't take chances. Do it NO MORE THAN 50% into your presumed survival window. . . . JO.Skip Robinson Southern California Edison Company SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU> wrote on 12/06/2005 06:39:31 AM: > Let's assume the following scenario: > "Disastrous" power outage occured, no alternate power source is > available, only UPS battery. Time for battery discharge is approx. 20-30 > minutes. > DASD is mirrored to remote site, system z/OS, DB2, CICS. > > The goal is to keep *remote* copy as consistent as possible. Additional > goal is to make system start possibly quick. > > > What operational scenario would be best in this case: > 1. Do nothing. At the remote site DB2 will backout all uncommited > transactions. > > 2. Try to issue > F CICSname,CEMT P SHUT > -DB2 STOP DB2 > $PJES2 > Probably the remaining time is not enough to finish the commands above. > > 3. Try "radical" commands like > F CICSname,CEMT P SHUT I > -DB2 STOP DB2,FORCE > $PJES2,TERM > > 4. Other (???) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
