Actually, Skip, we were almost at the point to be able to do this when 
we moved to the new data center. And, the procedure is very similar to 
the way the move was done. With the new data center, both the primary 
and secondary site had double disk, so that we could mirror in either 
direction and flashcopy to the secondary copy and run off of it.

For a test switch to the secondary site, follow the same procedure we 
used to do the move:
Clean shut down of primary site
Run GDPS script to do XRC recovery
Shut down XRC and GDPS systems
Start XRC and GDPS systems at primary site
Run GDPS script to start mirroring with NOCOPY (since primary and 
secondary are duplicates of each other)
Start production systems at secondary site
(There are also the network changes for DR that are to be done in here)

What was missing when I left:
The ability to run XRC/GDPS at primary (although it could also be 
accomplished using push from secondary instead of pull)
The GDPS configuration to mirror back must be kept up to date

Going back to primary would follow the same process. If you still have 
the procedure for the data center move, that will get you 95% of the way 
there.

Of course, this is only good for moving between sites and it requires 
production outages. In a true DR, there is probably no DASD to mirror 
back to, even if using push instead of pull. When we had the z10 outage, 
this would have worked (if we had the duplicate DASD at that time). But 
as you mentioned, deciding to fail over when you feel you will get your 
primary site back soon is a tough choice.

For SCE, the challenges are the secondary site just being a single CEC 
that has to have a CBU upgrade to run any production work, so this would 
all have to happen in a single weekend. You don't want to run at the 
backup site any longer than necessary if it is not a true disaster.

On 2/13/19 3:41 PM, Jesse 1 Robinson wrote:
> Willy-nilly is about notification and opportunity for preparation. For 
> example, management declares a surprise DR drill on a Saturday morning. So 
> the techs execute their well-rehearsed swap-over plan and begin running 
> production at the DR site. Real live transactions with actual customer data. 
> The old production site is now obsolete.
>
> Then Sunday at noon management decides to roll back before the new week 
> starts off. There is no time to plan. No time to test. The entire environment 
> has to copied back to prod overlaying the old data. And it has to work from 
> the get-go.
>
> Can anyone step up to that challenge? If not there could be some serious 
> willy damage.
>
> .
> .
> 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
> [email protected]
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] On 
> Behalf Of Ed Jaffe
> Sent: Tuesday, February 12, 2019 4:04 PM
> To: [email protected]
> Subject: (External):Re: Wells Fargo? Well f*&%#d at the moment: Data center 
> up in smoke, bank website, app down . The Register
>
> On 2/11/2019 7:06 PM, Jesse 1 Robinson wrote:
>> All of this bodes ill for willy-nilly switching back and forth between data 
>> centers unless there's some secret trick(s) I don't know about.
>
> I don't know the tricks either. Guess I need to attend more DCM 
> Project-sponsored sessions at SHARE... ;-)
>
> I can attest that we have a number of customers that swap workloads between 
> two sites a couple/few times a year. (Does that count as
> willy/nilly?)
>
> We have one or two with a third site in the mix! Yikes!!!
>
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://www.phoenixsoftware.com/
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to