My reservation about running a sysplex over a network (as opposed to direct link cables) is not merely latency. We went with XRC for DR because it's asynchronous and therefore fairly tolerant of network delays. For me the real problem is that an entire extended sysplex may be at risk in case of network disconnection. In the early days for us (late 90s) we experienced fairly frequent network interruptions that caused mirroring to suspend. There was no impact on the production sysplex itself, and mirroring could be resumed with minimum effort. Losing XCF connection to a sysplex member would be a whole nother level of impact that I've never been willing to sign up for even though our network today is far more reliable than it was 20 years ago. Likewise connection to common sysplex DASD would be subject to the same level of uncertainty.
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-543-6132 Office ⇐=== NEW
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Rob Schramm
Sent: Wednesday, January 10, 2018 8:09 AM
Subject: (External):Re: SYSPLEX distance
I was part of a group that ran a parallel sysplex that was 13 miles apart.
The time it takes the light to travel adds up. This was back in 2007. It
worked. It ran that way for at least a few years. It was not a GDPS setup. I think it was EMC disk at the time.
On Sun, Jan 7, 2018 at 12:13 PM Jesse 1 Robinson <***@sce.com>
> 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 <(323)%20715-0595> Mobile
> 626-543-6132 <(626)%20543-6132> Office ⇐=== NEW ***@sce.com
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU]
> On Behalf Of Alan(GMAIL)Watthey
> Sent: Saturday, January 06, 2018 11:43 PM
> To: IBM-***@LISTSERV.UA.EDU
> 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.
> Alan Watthey
> -----Original Message-----
> From: Timothy Sipples [mailto:***@SG.IBM.COM]
> 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN