Unattended System Save

[MichaelT]

I am trying to run an unattended system save. Currently, it only saves QDOC and IFS. Below are the DSPTAP results and the CL that is being used. The job ran under QCTL. It errored out needing to be initialized, so I answered INZ and proceeded to run until completion. The tape is new, so there was nothing on it. It did NOT leave a joblog. It ran on Sunday morning when nobody is on the system. We just upgraded our box to V7R2M0 L00. Any ideas what I'm doing wrong?


File Block Recg Record Block File Mvol Mvol Date Expiration System
Data File Label Sequence Format Tech Length Length Length Ind Sequence Created Date Where Created
QDOC 0000000001 *U P 00000 262144 0000001777 0000000001 09/04/16 *PERM IBMOS400
SAV20160904 0000000002 *U P 00000 262144 0000082075 0000000001 09/04/16 *PERM IBMOS400


PGM
MONMSG MSGID(CPF0000)
ENDSBS SBS(*ALL) OPTION(*IMMED) ENDSBSOPT(*NOJOBLOG)
DLYJOB DLY(600)
SAVSYS DEV(TAP05) ENDOPT(*LEAVE)
SAVLIB LIB(*NONSYS) DEV(TAP05) ENDOPT(*LEAVE) +
ACCPTH(*YES)
SAVDLO DLO(*ALL) DEV(TAP05) ENDOPT(*LEAVE)
SAV DEV('QSYS.LIB/TAP05.DEVD') OBJ(('/*') +
('/QSYS.LIB' *OMIT) ('/QDLS' *OMIT)) +
ENDOPT(*UNLOAD) UPDHST(*YES)
PWRDWNSYS OPTION(*IMMED) RESTART(*YES) +
ENDSBSOPT(*NOJOBLOG)
ENDPGM:

[EmmanuelW1]

Well, for one, you're not using the support for "batch restricted" - this is specified by using the BCHTIMLMT parameter of the ENDSBS command.

I would also add a check that you've actually reached restricted state - it's certainly possible that is the case given your 10 minute delay, but making sure would be better. One way is to add a MONMSG to the SAVSYS command, for the CPF3785 message, and a delay and branch back to SAVSYS if encountered.

I think currently, your global MONMSG is catching all errors - you can't run a normal batch job in restricted state.

Cheers,

Emmanuel

[john.sev99]

Apart from what Emmanuel has mentioned, I think it would pay to add a DSPJOBLOG OUTPUT(*PRINT) command before the PWRDWNSYS. This will give you a joblog so you can identify any errors such as what may be happening at the moment. As you have a global error, how do you know when something fails?

[tomliotta]

I'd also wait for restricted state rather than use DLYJOB. However I much prefer monitoring the QSYSOPR *MSGQ for message ID CPF0968. I'd rather loop through any received messages while also checking a possible time limit seems best. And a spooled joblog should also be created for any task like this.

Also, it's not clear if SAV DEV('QSYS.LIB/TAP05.DEVD') is really what's wanted. I'd guess that SAV DEV('/QSYS.LIB/TAP05.DEVD') is a better choice. A leading '/' should always be preferred if it's what is intended (and that seems very likely).

[EmmanuelW1]

Tom Liotta wrote:

"I much prefer monitoring the QSYSOPR *MSGQ for message ID CPF0968. "

Using a MONMSG on the SAVSYS command was, as indicated, just one way to do it.

I think the very best way is to use the QWCRSSTS API, which will return a status of 1 when in restricted state.

Cheers,

Emmanuel

[tomliotta]

I think the very best way is to use the QWCRSSTS API, which will return a status of 1 when in restricted state.

I use the API to test if restricted state is already in place, but I'll wait for the message when I want to know when the state arrives. Usually that test happens in a time window, so I want to be notified as soon as it happens. With the API used to trigger an action, it either needs to be called in a loop along with some useful delay between loop cycles or it's called possibly many times (hundreds? thousands?) using CPU that seems better freed up for jobs that should be doing end-of-job processing.

[EmmanuelW1]

Tom Liotta wrote:
"...or it's called possibly many times (hundreds? thousands?)..."

Well to each his own. We use a 30 second delay limited to 15 tries via a counter after the ENDSBS *ALL command. The program shoots a message out indicating how long it waited to reach restricted state. We don't have a beastly machine, and the program generally performs about 5 calls to the API. This past Sunday restricted state was reached at 00:21:15, and was detected at 00:21:43.

Cheers,

Emmanuel

[Rocky]

Are you still struggling with this? If so, I can share with you related code of mine. It's been working for several years without a hiccup.

[MichaelT]

Are you still struggling with this? If so, I can share with you related code of mine. It's been working for several years without a hiccup.

Well, it had a small hiccup last Sunday. I would welcome your code. Thanks.