Our DR site is >100KM from our production site. In the early days of serious mirroring for DR (mid/late 90s), running a single sysplex across that distance was out of the question. It wasn't just a timing issue--although that was enough reason not to try--but network technology of the day was too flaky to run a single sysplex reliably. Connectivity is far better today, but I would not bet day-to-day production continuity on it.
I think you would find a lot of complexity in trying to run a single sysplex. In particular, how would you handle mirrored DASD? The remote sysplex member would surely have to use the same physical DASD as the local member(s). If the local glass house failed, the DASD would presumably be unusable for the remote member. You would then have to re-IPL with the mirrored copy, so there would be an outage of uncertain duration. In our case, the goal is to be up and running within four hours, which includes time for applications to recover and verify the environment. That's a lot longer than your hypothetical one hour, but even with a remote member up and running, how long would take to switch over to it? I don't know where you're located, but we live in earthquake country where disruption can be widespread. The more you need significant separation for contingency, the less opportunity you have for running a single sysplex. . . 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 Alan(GMAIL)Watthey Sent: Saturday, January 06, 2018 11:43 PM To: [email protected] Subject: (External):Re: SYSPLEX distance Thanks to everyone for their insights and pointers on this matter. It is obviously going to be very complicated to predict what might happen if we increase from our current 0.3km to something like (say) 20km. The IBM Redbook I mentioned suggests an IBM service to analyse some data (presumably SMF) that can give some information. If that were to highlight our particularly bad transactions it would be very useful. I suspect we have some badly written ones that would be particularly susceptible to longer CF response times. Does anyone know if this service still exists and where one might find it? I'll see if I can find the 2017 information Timothy mentioned below as this is new to me (any pointers - here, offline or Sametime as appropriate). The Asynchronous CF feature was mentioned in an earlier response but we will have to upgrade our software to get there. However, that was already in the planning. I have no idea where the question originally came from but maybe they feel that with the two sites so close together, if they lose one system then they could very easily lose the other as well. This would affect our Business Continuity (Metro Mirror). Our DR site (Global Mirror) is safe being much further away but of course would realistically take at least an hour (on a good day and with a following wind) to get the end users connected in to. Regards, Alan Watthey -----Original Message----- From: Timothy Sipples [mailto:[email protected]] Sent: 04 January 2018 8:42 am Subject: Re: SYSPLEX distance Please make sure you take one recent (late 2016) innovation into consideration: Asynchronous CF Lock Duplexing. My understanding is that this recently introduced Coupling Facility feature offers performance improvements in many scenarios, including some distance "stretched" Parallel Sysplexes. IBM published some related performance test data only last year (2017). If you're looking at older references, you might be missing a lot. It could be helpful to understand the motivation(s) behind the question. As a notable example, does somebody want to create (or maintain) a "BronzePlex" to satisfy Parallel Sysplex aggregation rules? (Those rules are becoming less relevant now, at least, but that's a separate point.) As another example, if the focus is on protecting and preserving data, then it might make sense to stretch the storage but not the Sysplex. ---------------------------------------------------------------------------- ---------------------------- Timothy Sipples ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
