It does indeed leave a window open; however, I am not setting the rules. The ones who do are aware of it and are willing to accept the risk. They have set the parameters such that we must get the system back up within 12 hours, and that the system brought up be no more than 24 hours out of step. That is fully met by the test plans and does not require the additional hardware (3100+ devices) needed to create the tertiary copy.
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Brian Nielsen > Sent: Friday, November 12, 2010 7:35 AM > To: IBMVM@LISTSERV.UARK.EDU `-+``````++++ > > On Thu, 11 Nov 2010 13:10:49 -0800, Schuh, Richard > <rsc...@visa.com> wrot= > e: > > >In essence, we will be breaking the connections with the > main system > >at a time not previously disclosed to us, and will not be > allowed to go > >back to it or reference anything on it for the duration of the test. > >We will have to resync the dasd after the test has been > completed. The > >main system will stay up and running so that those who are > not part of > >the test can continue working. > > If you'll indulge me, I have a side question: When you break > the replication in order to perform a DR test this puts > updates to your production site at risk of loss should a real > disaster occur during your = > > DR test. Is there something else in your setup that > elimtates this risk = > > or has management signed off on the risk? > > To eliminate the risk I would expect a setup whereby the > mirrored copy = > > gets flashed to a tertiary copy and the DR test conducted > from the tertiary copy and replication is never broken. > > If you have an alternate setup that eliminates the risk I > would be interested in what it is. > > Brian Nielsen >
