Before building a second data center for D.R. (and other reasons), we
assigned a MAINT DDD disk to contain all the EXECs and files required
during D.R. It provided a single place to keep all the moving parts. It
also made it easy to TAPE DUMP that disk after D.R. with all the changes
made during the test, and then restore it when we got "home".
All the service machines that needed access had "LINK MAINT DDD DDD RR"
in their directory entries, preventing the requirement for an External
Security Manager to already be up before they could access the disk and
files. That LINK statement also served as a sort of audit file of what
needed the files.
One of the files on the MAINT DDD disk was (actually, the disk still sits
on spinning DASD even though it has not been used in this millennium)
called "HA$DRCT DIRECT" ("HA" being for Hewitt Associates, long before
being usurped for High Availability!), and another called HA$DRCT EXEC.
Those and all the other "HA$* *" files from a TAPE DUMP copy of the MAINT
DDD disk were TAPE LOADed to the D.R. site's MAINT 191 disk. With that
naming convention it was easy to house clean the MAINT 191 disk before we
left the site. The HA$DRCT EXEC would make a renamed backup copy of the
D.R. site USER DIRECT FILE, then append directory entries that we needed
to being our restore from their 1st level VM system. (Before leaving, we
cleaned out our files, renamed the D.R. site USER DIRECT, and ran DIRECTXA
twice.)
Since then, I've created a "NODAL CONFIG Y2" that contains centralized
device address information to be used based on the "SYSTEM_IDENTIFIER"
returned by "CP QUERY USERID", which is itself based on the CPU Model and
Serial Number defined in the "SYSTEM_IDENTIFIER" records in "SYSTEM
CONFIG" file.
Each service machine that needs specific device addresses based on the
system they are running on checks the "NODAL CONFIG Y2" (I'd rename it to
something else if starting again) before ATTACHing required devices to
itself. It keeps all that information in central place for easy changes.
Here's a partial cut/paste.
* This file is read by various REXX and GCS programs for use in
* normal operations and in disaster recovery both at "home" and
* at a Disaster Recovery provider site.
*SysCfgID Svm_Name Dtyp Rdev Comment
* CPC4 LPAR2
HALINVA1 VTAM CTCA 0C02 'CTC 0C02 to SYSB for RSCS SNANJE, Read1'
HALINVA1 VTAM CTCA 1C02 'CTC 1C02 to SYSB for RSCS SNANJE, Read2'
HALINVA1 VTAM CTCA 0C01 'CTC 0C01 to SYSB for RSCS SNANJE, Write1'
HALINVA1 VTAM CTCA 1C01 'CTC 1C01 to SYSB for RSCS SNANJE, Write2'
* CPC4 LPAR2
HALINVA1 VTAM CTCA 0C22 'CTC 0C22 to SYSC, Read1'
HALINVA1 VTAM CTCA 1C22 'CTC 1C22 to SYSC, Read2'
HALINVA1 VTAM CTCA 0C21 'CTC 0C21 to SYSC, Write1'
HALINVA1 VTAM CTCA 1C21 'CTC 1C21 to SYSC, Write2'
* CPC4 LPAR2
HALINVA1 VTAM CTCA 0C51 'CTC 0C51 to SYSE, Read1'
HALINVA1 VTAM CTCA 1C51 'CTC 1C51 to SYSE, Read2'
HALINVA1 VTAM CTCA 0C52 'CTC 0C52 to SYSE, Write1'
HALINVA1 VTAM CTCA 1C52 'CTC 1C52 to SYSE, Write2'
... and later ...
* CPC5 LPAR3 as of 20060815
RECOVERY VTAM CTCA 0C51 'CTC 0C51 to SYSE for SNA terminals, Read1'
RECOVERY VTAM CTCA 1C51 'CTC 1C51 to SYSE for SNA terminals, Read2'
RECOVERY VTAM CTCA 0C52 'CTC 0C52 to SYSE for SNA terminals, Write1'
RECOVERY VTAM CTCA 1C52 'CTC 1C52 to SYSE for SNA terminals, Write2'
RECOVERY VTAM CTCA 0C02 'CTC 0C02 to SYSB for RSCS SNANJE, Read1'
RECOVERY VTAM CTCA 1C02 'CTC 1C02 to SYSB for RSCS SNANJE, Read2'
RECOVERY VTAM CTCA 0C01 'CTC 0C01 to SYSB for RSCS SNANJE, Write1'
RECOVERY VTAM CTCA 1C01 'CTC 1C01 to SYSB,for RSCS SNANJE, Write2'
The point is, you can restore your system from the Sunguard 1st-level VM
floor system, and then if your production system is designed to take into
account the different device addresses between your production and D.R.
locations, the service machines that need specific device addresses can
adjust themselves when they start up so that you can bring up your
restored production system 1st level at your D.R. location.
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.
Thomas Kern <[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
03/12/2008 07:34 AM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: Disaster Recovery Scenarios
My take on the DR scenarios is that unless you are building your own
recovery site to match your production site, you can never guarantee the
device addressing. So, you need to build address configuration changes in
to
your DR Plan. You may not need to change some addresses from exercise to
exercise, but on our last test, we had to change addresses within seven d
ays
of the exercise.
Running your production z/OS or Linux under the vendor's floor z/VM syste
m
means you need to customize their directory, where running under your own
z/VM means you can predefine some of those entries. Our z/OS systems run
in
their own LPARs at home, but in predefined virtual machines at DR. This w
ay
the z/OS people don't need to do IO(whatever) changes. My linuxes only ne
ed
network definition changes which I will be prestaging before our next
exercise.
After 12+ years of DR heartburn, my feeling is it is easier to adjust MY
z/VM system than to adjust the DR vendor's floor system.
/Thomas Kern
/U.S. Department of Energy
/301-903-2211
/301-905-6427
The information contained in this e-mail and any accompanying documents may
contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if this
message has been addressed to you in error, please immediately alert the sender
by reply e-mail and then delete this message, including any attachments. Any
dissemination, distribution or other use of the contents of this message by
anyone other than the intended recipient is strictly prohibited. All messages
sent to and from this e-mail address may be monitored as permitted by
applicable law and regulations to ensure compliance with our internal policies
and to protect our business. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, lost or destroyed, or
contain viruses. You are deemed to have accepted these risks if you communicate
with us by e-mail.
