"QUIT" To BACKUP's "Quit or Continue" Returns No Error Msg

[Jack Trachtman]

We run our nightly tape backups via batch scripts. Ocassionally a job has a problem
with the tape or drive and the operator gets
a msg from BACKUP to respond either "Quit or Continue". We always have them reply quit and decide what to do next.

The problem I have is that replying Quit causes the job to exit (not abort) with an OK status (which I have confirmed with HP). We have a process that monitors our batch jobs and looks at completion statuses (via the ACCOUNTING record) and sees these jobs as successful!

Any suggestions on how I can get VMS to recognize a response of QUIT to the BACKUP question as a program error exit?

TIA?

[John Gillings]

Jack,
My experiment -

load a tape in a drive (with the wrong label)

$ BACKUP/ASSIST login.com MKA500:JUNK.BCK/SAVE
%BACKUP-W-MOUNTERR
%BACKUP-I-OPERASSIST

The operator message requested "specify option (QUIT, NEW tape or OVERWRITE tape)"

to which I responded "QUIT"

The BACKUP job then continued with

%BACKUP-E-OPREPLY, operator reply is "QUIT"
%BACKUP-F-ABORT, operator requested abort on fatal error
$ SHOW SYM $STATUS
$STATUS == "%X10A3819C"

Now, even if the severity of whatever condition you're asking about was not -F-, I'm sure the value of $STATUS would give you some clues, at least enough to distinguish between successful jobs, and those terminated by operator intervention (note that this is not necessarily the completion status of the JOB).

So, *immediately* after the BACKUP command, take a copy of $STATUS:

$ BACKUP whatever
$ stat=$STATUS

It *must* be the very next command after BACKUP. Examine the value, and if you decide it's the result of a QUIT, then you can artifically change the completion status for the job with the EXIT command. For example:

$ EXIT %XA3819C

will make the completion status of the job
%BACKUP-F-ABORT, operator requested abort on fatal error

How you decide what to do is up to you. You could have a set of completion status values that you consider to be acceptable and fail on anything else, or you could look for specific failure status values.

Rather than use a specific message, you can "convert" any status value to severity -F-. Assume you have the status in symbol "stat":

$ fatal=(stat.AND.%XFFFFFFF8).OR.4
$ EXIT 'fatal'

That way you'll keep the information in the message (hopefully telling you more about what actually happened), but still allow your monitor process to realise that the job failed.

[Mike Ford_2]

Another thing you should be able to do is set a $ on error then goto xxx before the backup command. At xxx then set a status on the exit which indicates a non-successful job
ie.

$ on error the goto abort
$ backup bla bla bla
$ bkupstatus = $status
.
.
$abort:
$ exit 'bkupstatus

This should set a status that accounting won't interpret as a successful termination

[Jan van den Ende · Accepted solution]

Mike,

Sorry, good idea, but won't work here!

$ ON ERROR evaluates $SEVERITY
but operator "QUIT" gives a $SEVERITY of "3",
which is an -I- (informational, or qualified) SUCCESS status, and NOT an error, so it will NOT trigger ON ERROR!
(read the original post again: that IS what the issue is about).

Carefully apply John's instruction: the FIRST command after BACKUP should be to save $STATUS (or $SEVERITY, the low bits of $STATUS), and evaluate THAT.

Proost.

Have one on me.

Jan

[Uwe Zessin]

Mike,
I don't think that logic is correct:

$$ type A.COM
$ on warning then $ goto XXX
$ backup a.tmp a.bck/save_set
$ BCKSTATUS1 = $STATUS
$ write SYS$OUTPUT "X1"
$!
$xxx:
$ BCKSTATUS2 = $STATUS
$ show symbol BCKSTATUS*


gives:
$$ @a
%BACKUP-W-NOFILES, no files selected from USER_XYZ:[ZESSIN]A.TMP;*
BCKSTATUS2 = "%X10A38400"
$$

You see, the assignment to "BCKSTATUS1" after "backup" is not executed.

[Jack Trachtman]

Thanks all