Hi Jeff
Why wouldn't you do them both in batch ? (just curious)
I don't really have a recommendation either way, or more exactly a good
reason for why I'd probably go with Option 1. I used BRMS for this which
meant that option 1 seemed to be a more natural fit. Whichever way you go,
build a timeout into your restart job to make sure it doesn't wait forever
for the SWA checkpoint when the inevitable error comes along.
There are some operations that will still bite you once you have reached a
checkpoint. For example, if you have any programs that save or restore or
objects they will fail if they attempt to use the objects in the SWA
library (at least in my experience). I saw some stuff at one site where
they transferred stuff around between machines using savf's and restored it
when it arrived at the target system but this bombed during the SWA
process. Kind of self evident that a library being saved wouldn't allow
restores...
I'll follow this thread with interest.
Regards
Evan Harris
I'm going to change most backups to use a SWA scenario. In a SWA
environment, you monitor a message queue for the checkpoint processing
complete. Is there a preference to one of the following ways of doing it:
Option 1
========
Controlling CL program
- calls a CL to stop QINTER, jobqs, etc.
- submits a job to QCTL that monitors the msgq for checkpoint
(when reached, this submitted job restarts QINTER, etc)
- performs the backup
- done
Option 2
========
Controlling CL program
- calls a CL to stop QINTER, jobqs, etc.
- submits a job to QCTL that performs the backup
- monitors the msgq for checkpoint
- restarts QINTER, etc
- done
In option 1, the SAVxxx commands are done interactive with the msgq
monitoring in batch.
In option 2, the msgq monitoring is done interactive with the SAVxxx
commands in batch.
Is there a caveat to one or the other of these?
--
Jeff Crosby
