DCL error checking

[Aaron Lewis_1]

I have a script to back up a bunch of directories.

At the top of the script I have:
on error then goto done

In the backup loop I have
on warning then continue

The other day, we had a parity error, and the backup just kept going. Parity is a fatal error, why did it not execute the 'On Error' statement.

[Steven Schweda]

It's not always easy to diagnose an invisible
command procedure with a vague description of
its behavior.

BACKUP /NOASSIST?

> Parity is a fatal error [...]

Perhaps not to DCL. What did BACKUP do when
the error occurred? What was its exit
status (if it actually exited)?

[EdgarZamora_1 · Accepted solution]

If you look at the help on "ON":

If you specified an error condition as the condition parameter,
the action is taken when errors equal to or greater than the
specified level of error occur.

I would say your "on warning then continue" superceded the "on error then goto done" that you executed beforehand.

If you really want to control this better, use SET NOON then test the status code after each backup command.

[Aaron Lewis_1]

Steven, the backup is noassit, parity is a falal error.

%BACKUP-S-COPIED, copied $1$DGA111:[UNV$I.;1
%BACKUP-S-COPIED, copied $1$DGA111:[UNV]BOSFE.COM;1
%BACKUP-E-FATALERR, fatal error on MKC600:[]FM1627.BCK;
-SYSTEM-F-PARITY, parity error

The backup loop just kept going, even though it was still getting more fatal errors. I received 1 of the positioning errors for each directory in the loop, after the initial parity error

%BACKUP-F-POSITERR, error positioning MKC600:[000000]FM1627.BCK;
-SYSTEM-F-OPINCOMPL, operation is incomplete

%BACKUP-F-POSITERR, error positioning MKC600:[000000]FM1627.BCK;
-SYSTEM-F-OPINCOMPL, operation is incomplete

[Mobeen_1]

Aaron, why don't you put a "set verify" in the start and at the end "set noverify" and post the output here along with the command file.....it takes only few mins to catch it :)

regards
Mobeen

[Steven Schweda]

I like the EZ explanation. (I don't think
that I ever read the HELP ON * carefully
before.)

[Karl Rohwedder]

We do issue a SET NOON before backup and run the backup inside a tmp. commandfile with
@'tmp'/out=...
After the backup the procedure scans through the output file to check for errors and other useful information (e.g. compression rates).

regards Kalle

[EdgarZamora_1]

Or you could put your "on warning" before the "on error". Examples:

CLCC1> @a
$ set ver
$ a = 1
$ on warning then continue
$ on error then goto err
$ backup x.zzz x.sav/sav
%BACKUP-W-NOFILES, no files selected from SYS$USERS:[EZAMORA]X.ZZZ;*
$ write sys$output "continued"
continued
$ exit

CLCC1> @a
$ set ver
$ a = 1
$ on warning then continue
$ on error then goto err
$ backup x.x mkz666:x.sav/sav
%BACKUP-F-PARSE, error opening MKZ666:[EZAMORA]X.SAV;
-RMS-F-DEV, error in device name or inappropriate device type for operation
$ err:
$ write sys$output "went to err"
went to err
$ exit

[Jan van den Ende]

Aaron,

if you want different banches teken on different error levels in DCL, you will simply have to specify them in ascending order of severity (as per the HELP text reproduced by Edgar)

$ on warning then
$ on error then
$ on severe_error then

The latter supercedes any former, but only on greater severity.

Reverse the order, and the later supercedes all previous.

hth

Proost.

Have one on me.

jpe

[Hoff]

My understanding is that the last ON command or the last SET NOON command wins. That there's no concept of multiple parallel ON levels within DCL.

Assume the following example and note the following deliberately bogus command xyzzy. This bogus verb should trigger a warning error.

$ on warning then goto w
$ on error then goto e
$ on severe_error then goto s
$ xyzzy
$ write sys$output "done"
$ exit
$w: write sys$output "warning"
$ exit
$e: write sys$output "error"
$ exit
$s: write sys$output "severe"
$ exit

If there were multiple levels, you'd expect to end up at the warning label here, but you actually end up at the done label -- this because the warning severity is less than the most recently declared ON severity level.

If what had been posted earlier had a goto rather than the continue, this behavior might have been more obvious. In the above DCL example, not that the warning branch is not taken; the processing falls through to done.

I might well be wrong here, as this is DCL after all...

[Steven Schweda]

Yes, EZ's first response was good. Then he
"improved" it. Carefully read, the HELP does
seem to be accurate, but it's less clear than
it could have been about the lack of
hierarchy in the "condition" parameter.

[Hoff]

Try the example I posted.

Based on what I see, ON mumble-lower THEN CONTINUE followed by any ON mumble-higher does not appear not meaningful; based on the test I tried, it's not the CONTINUE that's triggering here (otherwise the GOTO in the example would have fired), it's the ON mumble-higher that's suppressing the error branch for mumble-lower, and implicitly causing the appearance of a CONTINUE.

[Aaron Lewis_1]

Hoff, you are correct. i modified EZs example with a goto on the warning, and the script just contined to run. So the ON command only supports a single level of error checking. I will need to add in $STATUS or $SEVERITY checks.

[EdgarZamora_1]

Hoff is right (of course). I verified by using a goto instead of continue. I apologize for my incorrect second response.