Since we provide our own DR from one enterprise data center to another, we
have the luxury of knowing exactly the characteristics of the CFs in the
recovery environment. That allows to include both production and DR CFs in
one CFRM policy and to include them in the PREFLIST for all structures.
That in itself is not sufficient to prevent traumatic disruption in DR
because the old CFs are not simply 'forgotten' after abrupt disconnection
and IPL of systems in a 'cool' recovery site with mirrored DASD but no
structures at all in the 'new' CFs.
As suggested in this thread, our DR procedures were spawned by problems we
first faced 10 years ago. I freely admit that we've never gone back to
square one to see if a less disruptive procedure would now be possible.
This thread has inspired me look for a better way to do it. Especially
because we will soon have an opportunity to conduct a 'virtual DR' via
hardware upgrades. This will not be a test. ;-)
Tom Schmidt
<[EMAIL PROTECTED]
OFTWARE.COM> To
Sent by: IBM [email protected]
Mainframe cc
Discussion List
<[EMAIL PROTECTED] Subject
.EDU> Re: Cleanup a unconnected Coupling
Facility
05/14/2008 02:14
PM
Please respond to
IBM Mainframe
Discussion List
<[EMAIL PROTECTED]
.EDU>
On Wed, 14 May 2008 15:42:47 -0500, Field, Alan C. wrote:
>For DR we used to do this but for the last couple of years we define our
>home CFs (CF1 and CF2) in the CFRM policy. We also define the DR CFs
>(CF3 and CF4) in the same policy and in the structure preflist put
>(CF1,CF2,CF3,CF4),
>
>At home the structures allocate in CF1 and CF2. When we go to DR they
>allocate in CF3 and CF4. No need to delete and rebuild anything.
Yes, that's what we discussed doing for our upcoming test, too. The
compelling reason to do what we did this past Sunday was to
establish/confirm
procedures for a "Plan B" and possible "Plan C" at DR.
The problem with relying on the DR CFs is that the CFRM CF entries are
specific to the model and serial involved ... and are therefore too closely
tied
to the whims of the DR vendor. If the DR vendor du jour upgrades or
replaces
the CF system and give us appropriate notice then "Plan A" will work
without
deleting or rebuilding anything (as you say). Trouble is, that vendor
planning
communication hasn't been all that reliable or timely in the past. That
meant
that having a Plan B and a Plan C seemed like a really good idea.
I don't hate the idea of defining a fresh CFRM at the DR site; I dispute
the
widely held belief that there is no other option.
--
Tom Schmidt
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
