We've been mirroring 'all' DASD for 10 years. From the outset we chose XRC
over PPRC because the distance between data centers ruled out synchronous
mirroring. (Everything was slower in those days.) Our DR recovery would
require IPLs at the remote center. If your use of mirroring somehow allows
you to avoid system restarts, then you can ignore many of the following
points. We have a 'cool' site: mirrored DASD but no running system to use
it seamlessly. We have to IPL all necessary systems. Hence some data is
needed, other data is not. Our reasoning.
1. Don't mirror 'throwaway' data. For example, SORTWK and other temp data
is totally unnecessary after reIPL. Isolate all such data via SMS and
refrain from mirroring it. Total waste.
2. Don't mirror data that is otherwise backed up on a constant basis. For
example, our SMF MANx data sets are placed on a specific set of volumes.
SMF data is offloaded to tape and the data sets cleared frequently. In the
event of a disaster, lost SMF data is the least of our worries. Yet SMF
data is a drain on mirroring resources because it is hugely write
intensive.
3. For any volume that is not mirrored, provide a 'placeholder' volume for
DR. Placeholders are of two types:
(a) SORTWK and temp volumes require nothing more than a VTOC with a volser
that SMS at the DR site can utilize.
(b) Some data like SMF requires an actual 'image' of the volume containing
all data sets for normal IPL at the DR site. That is, the SMF objects must
exist on the volume with the proper allocations, but the actual data
contents are irrelevant. For this type, we schedule a job once a week to
synchronize SMF volumes and then cease mirroring immediately. Overhead is
brief and minimal.
So to the original question: where do page data sets fit? For us,
unequivocally, they are type 3(b) that need only specific allocations on
specific volumes. Like SMF, we synchronize them once a week but do not
mirror the actual data, which are totally refreshed on IPL at the DR site.
To summarize the three types:
- Mirror continuously
- Synchronize regularly only to assure proper allocations
- Don't mirror at all
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]
Frank Allan
Rasmussen
<Frank.Allan.Rasm To
[EMAIL PROTECTED] [email protected]
NMARK.DK> cc
Sent by: IBM
Mainframe Subject
Discussion List PPRC and page datasets
<[EMAIL PROTECTED]
.EDU>
05/07/2008 03:55
AM
Please respond to
IBM Mainframe
Discussion List
<[EMAIL PROTECTED]
.EDU>
Hello
Are there any rectrictions or recommendations about PPRC (metro mirror) and
volumes with page datasets?
Good ide, bad ide, some performance impact, recomented?
Venlig hilsen
----------------------------------------------------------------------
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
