We do something similar except because our locations are only 80km apart we can run Metro Mirror.
To do DR we flash to tertiary volumes using a small Z LPAR but looking at changing that to using CSM with practice volumes as per this video from the Washington Systems Center. https://www.youtube.com/watch?v=T9qi0SPclws&index=21&list=LLk5ckV6tZvGgV6GU1FD-6wg&t=204s We then IPL from the tertiaries using CBU. I had quite a few email exchanges with the presenter Paul which were very informative. He had since retired though. The next challenge is how to get back after a DR event. Larry On Tue, Feb 26, 2019, 1:17 PM Jesse 1 Robinson <jesse1.robin...@sce.com> wrote: > Replying to the original question. There may well be a better way to > manage DR than what we do, but we have not been pitched one in 20+ years. > We own both PROD and DR data centers and all contents. The DR site runs XRC > ('Global Mirroring for Z', a truly execrable name). Its only job in life is > to pull data from PROD and continuously update a full set of secondary > volumes that correspond to the full set of primary volumes. It runs on one > general purpose CP supported by enough CBU to mimic a full set of DR LPARs > including CFs. When we're ready for a test, we push a GDPS button to FLASH > the secondary volumes over to a tertiary set and make them look (almost) > exactly like the primary set. We IPL and run from the tertiary set. > Meanwhile mirroring continues to the secondary set so at any moment we > could enter a real DR with no data loss. > > The z/OS license on the DR box is ' ZNALC', which allows us to run DR but > no portion of production or application development. Even the skinflint > bean counters are satisfied that this is a good deal. We don't have to pay > any third party for resources. Nor do we have to schedule test windows. And > most important of all, in the case of a regional disaster--for SoCal read > earthquake--we would not have to compete with other clients for DR run time. > > If you're looking for some 'other way' to manage DR, be sure that these > issues are accounted for. Or else not critical for your enterprise. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Ambros, Thomas > Sent: Wednesday, February 20, 2019 11:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Disaster recovery, alternatives to CBU machine in > alternate site > > Currently we're handling our hardware or site level disaster recovery with > an essentially cold machine in an alternate site, a CBU entitlement allows > us to spin it up and run recoveries. We've been pitched CMP (Country > multiplex pricing) because there is a potential requirement to be able to > run out of one site or another for a period of months. One assumption is > that the capability stays in house. > > I've been asked to solicit this list for answers to a couple of > questions. Are there alternatives to either of these arrangements that > allows a customer to support production processing capacity in two sites > without incurring the extra cost of CMP, or even the CBU? If you've > implemented CMP, did it have an effect on your expenses one way or another? > > I don't know if these are appropriate questions in this forum but if they > are I'd be grateful to learn of alternatives we should look into. > > <snip> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
