Hal, I'm not so certain that you are agreeing to the same point that Skip is making. I take Skip's point as meaning that the success of any Remote Copy design requires attention to the creation of IO consistency in the event of a failure.
On the other hand your point to me applies to the ability of an application to recover from an abrupt failure, independent of whether Remote Copy is used or not. The ability to restart an application or a batch stream is not a delivered by Remote Copy. If a site fails the Online and Batch must recover in the same manner irrespective of whether the systems restart in the original centre, or fails over to the DR Centre. The open files may be recovered, deleted, rolled-back/forward, etc - whatever is required to get started. Disk Mirroring delivers a customer the same restart ability in both sites, providing IO Consistency is also delivered by the Remote Copy architecture. It doesn't matter whether restart is in the original copy or the mirrored copy, open datasets should already be dealt with by the application. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Hal Merritt > Sent: Wednesday, 22 June 2005 4:28 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: DASD and Mirroring > > Dead on. > > At point of failure, files that are closed are perfect, but the files > that are open are unusable. How can you tell which is which? > > The DASD Redbooks are very clear. There is no free lunch. Mirroring is > an excellent solution for a number of potential problems. But not all. > > HTH and good luck. > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
