I am absolutely not a hardware guy, so I tend to reduce hardware issues to simpler terms. First off, mirroring motivation was not part of this thread initially, so I didn't point out that our entire business case for mirroring was Disaster Recovery. Any technology that depends on 'letting things finish' to catch up at the remote side is ruled out. When the meteorite falls or the earthquake hits or the volcano blows its top, there is no data reconciliation grace period. We got what we got and nothing more. Data consistency is far more important than data currency.
So we started with XRC around 2000 using ESCON devices over 'conventional channel extension'. I believe the vendor was CNT but cannot find any doc. We never seriously considered PPRC--at the time only synchronous--because of distance (~ 120 KM) and the aforementioned need for data consistency. The killer was ESCON protocol, not circuit speed, which XRC can live with but not PPRC. A synchronous technology will slow down production I/O to allow remote I/O to complete. That impact was not acceptable. Then along came DWDM, which promised to free us from vendor tentacles and monthly bills. But ESCON over DWDM was a disaster, far slower than the alternative. So we plunged headlong into the still evolving FICON arena. It was a bumpy road, but we eventually got it working. ESCON switches were replaced with FICON switches. Over the years everything has gotten faster and nimbler. BTW despite the dominance of DR in the equation, we used the same technology for two separate data center moves. In both cases, we went into a 'DR exercise' but stayed put in the new location. In other words, a DR solution can work for planned relocation, but not necessarily vice versa. . . 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 Mike Schwab Sent: Friday, June 08, 2018 3:29 PM To: [email protected] Subject: (External):Re: [EXTERNAL] Re: PPRC-XD vs Async PPRC ESCON is synchronous, where after sending a buffer, it would wait for acknowledgement before sending the next buffer. FICON is async, where it sends buffer after buffer without waiting. If it doesn't get an acknowledgement within a certain time frame it would resend the lost buffer. On Fri, Jun 8, 2018 at 5:15 PM Ron hawkins <[email protected]> wrote: > > Radslaw, > > Have you confused a few things when explaining the difference between > synchronous and asynchronous, and ESCON compared to FICON? > > Buffer credits are synonymous to DIBs, and a large number of buffer credits > provided by Fiber Channel switches allowed the connection to be full of > frames end to end over a greater distance than FICON. > > The buffer credits, however, did not have anything to do with reducing the > RTD spent in the "talking" as you put it. That is purely a function of two > round trips required by Fiber channel compared to 9 (I think) required by > ESCON. Buffer credits and number of DIBs affected transfer rate, not RTD. > > Asynchronous remote copy still requires the provision of adequate buffer > credits over distance to maintain line speed, where the number is a function > of line speed and distance. Having no distance related impact on response > time at any distance is the advantage of asynchronous. Synchronous cannot > guarantee zero data loss, so I struggle with coming up with advantages beyond > that myth. > > Ron > > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf Of > R.S. > Sent: Friday, June 8, 2018 3:11 AM > To: [email protected] > Subject: Re: [IBM-MAIN] [EXTERNAL] Re: PPRC-XD vs Async PPRC > > 1. PPRC-XD and PPRC are very different animals. PPRC-XD is capable to work on > any distance, while PPRC is limited by speed of light which is not planned to > change. > 2. ESCON vs FICON did huge difference not only in speed (bit per second), but > also in something called credit buffers. In very simple word A talks to B, > but A can say many words before B acknowledge it. > Many words can be "in transit", which makes the protocol quite independend on > link length. This is better visible when A is host and B is CU (DASD or tape). > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 2018-06-08 o 06:10, Sankaranarayanan, Vignesh pisze: > > Hi Skip, > > > > Looks like you tried PPRC over "long distance" and had a bad exp back then. > > PPRC-XD should work fine for actual long distance, assuming that the LPAR > > itself can get an outage to let the final delta synchronize. > > > > – Vignesh > > Mainframe Infrastructure > > > > -----Original Message----- > > From: IBM Mainframe Discussion List > > [mailto:[email protected]] On Behalf Of Jesse 1 Robinson > > Sent: Thursday 07-Jun-2018 23:52 > > To: [email protected] > > Subject: [EXTERNAL] Re: PPRC-XD vs Async PPRC > > > > Data consistency was one of two reasons we chose circa 2000 to use XRC > > rather than PPRC. I know the technology has changed, and I've been *told* > > that PPRC is now capable of maintaining consistency, but I have not seen it > > in action. The other reason for XRC BTW was the synchronizing problem: we > > could not tolerate the I/O delay waiting for remote confirmation from 120 > > KM via ESCON. In 2000, everything was slower. Now we use DWDM via FICON. > > > > . > > . > > 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 R.S. > > Sent: Thursday, June 07, 2018 4:10 AM > > To: [email protected] > > Subject: (External):Re: PPRC-XD vs Async PPRC > > > > W dniu 2018-06-06 o 18:18, Sankaranarayanan, Vignesh pisze: > >> Hello All, > >> > >> Please could you point me to any doc explaining the differences between > >> the 2. > >> Any important, obscure, techdocs or KB page or some such as well.. ? > > Fundamental difference is data consistency. > > PPRC-XD is *inconsistent* copy during most of the time. Inconsistent is > > unusable. You have to quiesce the production and wait a little until the > > delta become zero (the copy become consistent). > > Asynchronous copy like XRC, SRDF/A, HARC is different. It is > > *consistent* copy - data on secondary site is usable, but is not current. > > Of course the time delta is small, but the most important is you don't have > > later data while earlier data is missing. > > > > -- > > Radoslaw Skorupka > > Lodz, Poland > > > > > > -------------------------------------------------------------------- > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO > > IBM-MAIN > > > > MARKSANDSPENCER.COM > > ________________________________ > > Unless otherwise stated above: > > Marks and Spencer plc > > Registered Office: > > Waterside House > > 35 North Wharf Road > > London > > W2 1NW > > > > Registered No. 214436 in England and Wales. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
