Jeffrey brings up a good point to remember when involved with remote mirroring of data.
There are some errors that occur, perhaps especially because of program errors, where you simply do not know that the data is bad until well after the time for asynchronous mirroring to have completed. In this case, you have two copies of the bad data. There is a value to have point in time copies that are taken before major updates take place in the application data that can be used as recovery points should you encounter program problems that result in corrupted data. Also, these situations can be handled with Log analysis software through surgical repair of the data as opposed to normal recovery processes. Tom Moulder -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Deaver Sent: Tuesday, January 02, 2007 9:53 AM To: [email protected] Subject: Re: Data replication at a remote site - elementary doubt >When you implement synchronuous (or asynchronuous) copy of your DASD >data to a remote site, is it necessary for the remote site to have a >z/OS system active? No. We (async) mirror between two STK V2X4f arrays and there is no host attached at the hot site until we want to use the data there (either for a test or a DR situation) >and until you issue commands that stop the >mirroring (depending on how implemented), the remote site can't have >anything but read access to the data, if at all. Actually, because we use remote snapshot on our remote disk, we can continue with production async mirror process and IPL to a copy of the data on the remote disk with the hot site's MF hardware. We do this every time we have a DR exercise. We have three copies of the data on the remote disk... 1) The staging copy where the async mirror data is written 2) Copy 1 which is remote snapped every other day 3) Copy 2 which is remote snapped every other day opposite copy 1 So for a DR test we might plan on IPLing Copy1, knowing that the async data will continue to be written to the staging area, and then to Copy 2 for the daily 'synchpoint'. Jeffrey Deaver, Engineer Systems Engineering [EMAIL PROTECTED] 651-665-4231(v) 651-610-7670(p) ---------------------------------------------------------------------- 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 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.16.2/613 - Release Date: 1/1/2007 ---------------------------------------------------------------------- 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
