In my earlier post, I described categories of data: mirror continuously,
synchronize only, don't mirror at all. I didn't mention spool.
When we started this 10 years ago, we were using conventional ESCON channel
extenders from a well-known vendor in that biz. Bandwidth was a
consideration, but other limitations of channel extension were more
important. We opted not to mirror spool (but synchronize periodically) on
the grounds that production output was mostly sucked up by an output
manager product on DASD that *was* mirrored. The nagging problem we had
trouble solving was this: in the event of a sudden break, how would we
figure out exactly where we got interrupted in order to resume unfinished
processes? With no spool or SMF (previous post), how could we determine
what was in progress at what stage?
As time went on, advancing technology allowed us to move to FICON over
DWDM. Everything got way faster. We flirted with the idea of mirroring the
*alternate* checkpoint and the spool volumes. Primary checkpoint still
seemed daunting. Then one day our XRC guru turned on mirroring for the
entire JES2 array. The effect was barely noticeable. Problem solved. Now we
warm start JES in DR and pick up wherever we left off in production. My
recommendation: try mirroring the entire spool and monitor performance. If
it looks OK, leave it on. You'll avoid a lot of recovery problems.
.
.
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]
Mark Zelden
<[EMAIL PROTECTED]
CHNA.COM> To
Sent by: IBM [email protected]
Mainframe cc
Discussion List
<[EMAIL PROTECTED] Subject
.EDU> Re: PPRC and page datasets
05/08/2008 08:28
AM
Please respond to
IBM Mainframe
Discussion List
<[EMAIL PROTECTED]
.EDU>
On Thu, 8 May 2008 10:23:37 -0500, Mark Zelden <[EMAIL PROTECTED]>
wrote:
>
> We
>also don't mirror spool for all but a couple of very small environments
>(one sysplex has about 70 3390-3 volumes we don't mirror). We accept
>that anything in the spool at the time of a disaster is lost. This
wouldn't
>be much as we have output control software.
That came out wrong. Obviously if that environment needs 70 spool
volumes there could be a lot of data lost. What I meant to say is that
it wouldn't be much loss of anything importance since all the important
stuff
is managed by the output control software. Anything in the spool
waiting to print that was production could be re-spooled. Test /
programmer
output... who cares.
>If network bandwidth wasn't
>a consideration, we would mirror everything as it does make the process
>simpler.
>
--
Mark Zelden
----------------------------------------------------------------------
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
