Mirroring didn't change the way we do things at my client. Going back to
tape restore, mirroring to vendor DR site, or in-house mirroring which
is done now, we used a "new" XCF and CFRM data set for DR and all
the rest remained. By "new", I mean freshly formatted and never
used couple data sets that are pointed to via different IPL parms.
A couple of sysplexes using GRS STAR load the CFRM at IPL via
COUPLExx (avail. since z/OS 1.2 IIRC). When it was a vendor's
site for DR the policy couldn't be written to the couple ds until we knew
what CF we would get, and that was done from a one pack system. After
DR was move "in-house", it was pre-staged and I think the DR CFs
may now be in the prod CFRM policy for those sysplexes and they
are IPLed with the production CFRM couple ds (some cleanup
commands are needed after IPLing at the DR site).
LOGR has always been an issue, especially with tape restore. With
mirroring some things worked and others still had problems due to
data in the CF and an active system at the time of the "snap" that
we IPL from. So when we used tape restore, after we came up
we used my LOGRREXX exec (see my web site / CBT file 434)
to delete / define all logstreams. Using a new or DR LOGR
couple ds doesn't do anything for the catalog or the data sets
on your logr volumes (hence the delete/define using the one that
is restored or mirrored from production). Once we started mirroring
we only deleted CICS and RRS logstreams. That forces an RRS
cold start (you actually only have to delete/define the RM.DATA
logstream for this). And I think CICS may be optional based on
the way CICS is started with a certain SIT parm ("initial"?). Be
since it doesn't matter, we've left the delete/define of CICS
logstreams in our procedures. Other logstreams don't seem to have
a problem. That means I can come up at DR and see all the operlog
that had been offloaded to DASD for example.
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
On Wed, 28 Dec 2011 14:41:49 -0500, Mark Jacobs <mark.jac...@custserv.com>
wrote:
>It would be SO nice to have a mirrored DR, but alas no. Thanks for your
>comments.
>
>Mark Jacobs
>
>On 12/28/11 14:04, Skip Robinson wrote:
>> We use *all* couple data sets in DR, just not necessarily the mirrored
>> copies.
>>
>> -- Sysplex, ARM, SFM, BPXMCDS, and WLM data sets are mirrored from
>> production.
>>
>> -- CFRM data sets are created and populated with the (presumed) current
>> CFRM policy from the driving system before first IPL. This process is
>> required for GRS star, which must have an active structure at IPL. When
>> you create a CFRM policy, you can point to any couple data on any volume.
>>
>> -- Logger data sets are created from the driving system before first IPL
>> but populated with the (presumed) current logger policy from the newly
>> IPLed DR system. When you create a logger policy, the policy can only go
>> to the current active logger data set.
>>
>> -- 'Presumed current' is based on the ISPF last update stats in the
>> (mirrored) common policy data set.
>>
>> -- During the first IPL, there is a WTOR for each of the newly created
>> data sets; it requires 'C': go with PARMLIB specification rather than last
>> used.
>>
>> .
>> .
>> JO.Skip Robinson
>> SCE Infrastructure Technology Services
>> Electric Dragon Team Paddler
>> SHARE MVS Program Co-Manager
>> 626-302-7535 Office
>> 323-715-0595 Mobile
>> jo.skip.robin...@sce.com
>>
>>
>>
>> From: Mark Jacobs<mark.jac...@custserv.com>
>> To: IBM-MAIN@bama.ua.edu
>> Date: 12/28/2011 10:11 AM
>> Subject: Re: Couple Data Sets - DR Considerations
>> Sent by: IBM Mainframe Discussion List<IBM-MAIN@bama.ua.edu>
>>
>>
>>
>> Regarding the WLM couple datasets, no we don't have a reason other than
>> the desire not to run with some production couple datasets, and some
>> specifically for DR.
>>
>> Do you use your production logr couple dataset, or one specifically for
>> DR? If the latter how do you keep the two in sync since AFAIK you can't
>> add/change logger entries in a specific couple dataset, only the active
>> one.
>>
>> Mark Jacobs
>>
>> On 12/28/11 12:37, Skip Robinson wrote:
>>
>>> We provide our own DR between data centers with fully mirrored disk, but
>>> we still handle couple data sets in a manner similar to yours. However,
>>>
>> we
>>
>>> do not create new WLM data sets. Do you have a specific reason for doing
>>> so? We (OS sysprogs) are caretakers of CFRM and logger policies, which
>>>
>> can
>>
>>> be recreated before (CFRM) or immediately after (logger) the first IPL
>>>
>> by
>>
>>> automated batch processes. But WLM AFAIK requires ISPF and manual
>>> involvement by the performance/tuning group, who owns WLM policies.
>>>
>> We've
>>
>>> never seen a need to tailor WLM for the DR environment.
>>>
>>>
>>> From: Mark Jacobs<mark.jac...@custserv.com>
>>> To: IBM-MAIN@bama.ua.edu
>>> Date: 12/28/2011 06:53 AM
>>> Subject: Couple Data Sets - DR Considerations
>>> Sent by: IBM Mainframe Discussion List<IBM-MAIN@bama.ua.edu>
>>>
>>>
>>>
>>> We recover three sysplex's at DR, two single system sysplexes and one
>>> multi-system parallel sysplex. Since we don't utilize any data
>>> replication processes, we still perform DR via full volume backups and
>>> restores using our providers floor system.
>>>
>>> The two single system sysplexes use their production couple datasets at
>>> DR, but we have a separate set of DR couple datasets for the parallel
>>> sysplex that we populate at DR (mainly CFRM, LOGR, WLM, the others we
>>> don't care about at DR).
>>>
>>> Just wondering how everyone else is doing it.
>>>
>>>
>>>
>>
>>
>
>
>--
>Mark Jacobs
>Time Customer Service
>Tampa, FL
>----
>
>One of life's greatest mysteries is how the boy who
>wasn't good enough to marry your daughter can be the
>father of the smartest grandchild in the world.
>
>Yiddish Proverb
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
