Something we do:
when the daily disaster backup is taken, the server stores a file with
a certain name on AUTOLOG1's 191. As soon as the AUTOLOG1 191 is
DDRed, the file is removed.
The PROFILE EXEC of AUTOLOG1 & AUTOLOG2 checks for this file. If it
is found a QUERY is sent to the operators, asking them to tell if it
is an IPL after a disaster, or -if by bad luck- the system went down
during the DDR of AUTOLOG1 191.
In case of disaster, AUTOLOG1 and AUTOLOG2 perform a minimal startup
(RACF, VMTAPE&co; and VMOPER is replaced by PROP with a PROP RTABLE to
handle tape dismounts. The recovery people have manually to remove
this special file when the restores are complete.
2008/3/12, Mike Walter <[EMAIL PROTECTED]>:
> 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" <[email protected]>
> 03/12/2008 07:34 AM
> Please respond to
> "The IBM z/VM Operating System" <[email protected]>
>
>
>
> To
> [email protected]
> 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.
>
--
Kris Buelens,
IBM Belgium, VM customer support
