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.

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

Return to Archive home page | Return to MIDRANGE.COM home page