We've been XRC mirroring DASD between data centers about 100 KM apart since
the late 90s. When we started, we were using much slower technology than we
have today. DWDM over 'dark fiber' in conjunction with modern RAID DASD
have changed the metrics of what can or cannot/should not be mirrored.
In the beginning, we did not mirror the JES spool at all because we deemed
the cost too high. (We've never used CF for checkpoint.) We defined 'place
holder' volumes that allowed for a cold start during DR using a copy of the
production init deck. The view was that we could always rerun any jobs
whose output had not already been pulled off spool by sysout archival
software. The greater concern over time was that without a current snapshot
of the JES queues, we could not easily figure out exactly where we had left
off at the moment of mirror breakage. In a twenty step job, where did we
die and what needed to be rerun? How would we even know which jobs were
running at the time?
Rather than solving that specific problem, we eventually tried mirroring
the entire spool. By this time conventional channel extension had been
replaced by DWDM. The DASD was hugely faster at both ends. When we actually
turned on spool mirroring for the first time, we could hardly measure a
blip in XRC traffic. We were astounded at how simple the complete solution
turned out to be.
So, if your XRC transport technology supports it, I highly recommend
mirroring your entire spool.
1. Leave your primary checkpoint in the CF if you find benefit in that
configuration.
2. Mirror your secondary checkpoint and all spool volumes.
3. In DR, IPL with the mirrored checkpoint as primary.
4. As soon as practical, reconfigure JES to get your primary checkpoint
back in a local CF.
It's important to remember that the primary/secondary checkpoint
architecture evolved over decades to allow recovery from loss of the
primary. Remember when DASD volumes used to drop like flies in a
smokehouse? It wasn't that long ago. Much of what gets written to the
primary checkpoint provides for serialization of JES resources in a MAS. In
DR, the secondary checkpoint is a pretty reliable starting point for
mapping the existing spool data. That's what it was designed to do, and
refinements over many years have made it work extremely well. Chances are
that your JES in DR will come up cleanly with minimal complaints. What
can't be mapped exactly will be repaired or if necessary purged in order to
yield a fully functioning system. You will lose very little data in
recovery.
A fully mirrored spool has solved all sorts of problems for our DR. Give it
a try!
.
.
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]
Andy White
<[EMAIL PROTECTED]
OM> To
Sent by: IBM [email protected]
Mainframe cc
Discussion List
<[EMAIL PROTECTED] Subject
.EDU> JES2 check point in CF and DR
09/22/2007 05:43
PM
Please respond to
IBM Mainframe
Discussion List
<[EMAIL PROTECTED]
.EDU>
Anyone out there mirroring their DASD either SRDF or XRC, i'd like to know
how you handle the JES2 check point.
We currently have our primary check point in the CF and second one
on DASD. We know they aren't in SYNC maybe a few writes behind on DASD. We
mirror using IBM XRC to another site for DR purposes. We are thinking of
taking both check pints and moving it to DASD so both check points are
mirrored.
I guess the basic question we are asking ourselves is it worth
putting the check point back on DASD and loose the benefit of the CF or
keep it where it is an the heck with a few pieces of output that might be
lost at the time of a disaster.
If your mirroring and have gone down this road what have you done
and why? Thanks
Andy
----------------------------------------------------------------------
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
