If this helps: We run a parallel sysplex with sites at 16 - 18 km (2 separate routes with some difference in distance) with active systems and CFs at both sites, without problems. Most Sync CF Requests to the Remote CFs are converted to Async. To minimize the Async/Remote CF delays, we configure structures over the CFs in such a way that the most busy or most important structures are in the busiest or the most important site. We do not use System Managed Coupling Facility Structure Duplexing. All our applications are able to recover their structures well. SMCFSD's inter-CF communication would add a number of elongated delays to each CF update request. The advantage of SMCFSD is that each site has a copy of the structure and intelligence can chose the nearest (=fastest) CF for read requests.
Kees. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Alan(GMAIL)Watthey > Sent: 07 January, 2018 8:43 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: 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:sipp...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
