Operating System - OpenVMS
1748198 Members
2578 Online
108759 Solutions
New Discussion

BACKUP 8.3 $SEVERITY not set to error

 
SOLVED
Go to solution
Sean OBanion
Occasional Advisor

BACKUP 8.3 $SEVERITY not set to error

I'm testing some error hadling involving BACKUP during a copy operation of a single file from one volume to another.

 

OpenVMS 8.3 Alpha, patch level unknown.

 

In order to test the error handling, I need to force BACKUP to have an error.

I've chosen to have filled the output volume such that the copy cannot succeed.

BACKUP does indeed fail, but the exit status is 1, success.

 

$ set noon                      !<--- To continue to error handling if there is an error

$ BACKUP/IGNORE=INTERLOCK/PROGRESS_REPORT=10 -

  DISK3:[DATA]INFILE.DAT DISK2:OUTFILE.BCK

%BACKUP-E-OPENOUT, error opening USER_DISK4:[ARCH2]OUTFILE.BCK;1 as output

-RMS-F-FUL, device full (insufficient space for allocation)

.

.

.

$ set on

$ !

$ BackupStatus = $STATUS

$ BackupSeverity = $SEVERITY

$ show sym BackupSeverity

  BACKUPSEVERITY = "1"

$ show sym BackupStatus

BACKUPSTATUS = "%X00030001"

 

Sean O'Banion


Well, technically, yes and no.
7 REPLIES 7
Steven Schweda
Honored Contributor

Re: BACKUP 8.3 $SEVERITY not set to error

 
John Gillings
Honored Contributor

Re: BACKUP 8.3 $SEVERITY not set to error

Sean,

   The symbols $STATUS and $SEVERITY result from the immediately preceeding DCL command. Every DCL command will set $STATUS and $SEVERITY. That includes assignment statements and all SET commands. Thus your example:

 

$ BACKUP (whatever)
$ SET ON
$ BackupStatus = $STATUS
$ BackupSeverity = $SEVERITY
$ show sym BackupSeverity
  BACKUPSEVERITY = "1"
$ show sym BackupStatus
BACKUPSTATUS = "%X00030001"

 

tells us that the SET ON command was successful, as was the assignment of symbol BackupStatus.

 

You need to capture $STATUS immediately following the command you're interested in. Furthermore, for a single command, you can get $STATUS or $SEVERITY, but not both. Use $SEVERITY if you're really only interested in the severity. If you need more detail, get $STATUS and derive severity:

 

$ SOME-COMMAND
$ stat=$STATUS
$ sev=stat.AND.%X7

 

 

A crucible of informative mistakes
Sean OBanion
Occasional Advisor

Re: BACKUP 8.3 $SEVERITY not set to error

According to the online DCL Dictionary entry for SET ON, $STATUS and $SEVERITY are set regardless of the state of ON (see below).  However, the example in the User’s Manual does have the capture of both inside the SET NOON & SET ON, so I updated my code to reflect that, with no change in behavior.

 

Further, I noticed that the output file is not created even though BACKUP continues to execute, reporting activity through the /PROGRESS qualifier. Then I removed /PROGRESS, in case $STATUS was reporting the success of that, but there was no impact.

 

“Use the SET NOON command to override default error checking. When SET NOON is in effect, the command interpreter continues to place the status code value in $STATUS and the severity level in $SEVERITY, but does not perform any action based on the values. As a result, the command procedure continues to execute no matter how many errors are returned. “

Sean O'Banion


Well, technically, yes and no.
Hoff
Honored Contributor

Re: BACKUP 8.3 $SEVERITY not set to error

Whatever you're doing here (with BACKUP and the earlier /PROGRESS tests and now some related error handling) is beginning to look like you're trying to drive screws into a board with a hammer.   It'll work, but not all that well.    (Kind of like the HPSC forum software in that regard, but I digress.)

 

Please consider telling us what particular problem you're trying to solve here, rather than discussions around troubleshooting a particular solution; what you're solving, rather than how you're trying to solve it.  (There may be an alternative tool that can track progress, or whatever it is that you're trying to do here.  There's definitely file-copy source code around; I've posted some.)

 

SET NOON and the ON {severity} and related error-handling mechanisms within DCL are obviously related to error handling, but there appears to be some confusion on the interactions.

 

Most every command sets the $severity and $status.  While there are exceptions to this (eg: symbol assignment), the general rule of thumb is to immediately save off the status or severity values, and only then do whatever error handling or other commands that might be required.

Steven Schweda
Honored Contributor

Re: BACKUP 8.3 $SEVERITY not set to error

 
John Gillings
Honored Contributor

Re: BACKUP 8.3 $SEVERITY not set to error

I have to disagree with Hoff...

 

> While there are exceptions to this (eg: symbol assignment),

 

ALL DCL commands set $STATUS and $SEVERITY. Simple demonstration:

 

$ exit %x1234
%SYSTEM-F-FILNOTPUR, error deleting !AS
$ stat1=$status
$ stat2=$status
$ sev=$severity
$ show sym/all
  SEV = "1"
  STAT1 = "%X00001234"
  STAT2 = "%X00030001"

 

 So, stat1 has the $STATUS result from the EXIT command. stat2 is the $STATUS from the assignment of stat1 and sev is the severity of the assignment to stat2. You must capture $STATUS as the command IMMEDITELY FOLLOWING the command you're interested in.

 

I'm not sure what Sean expects from a SET ON executed AFTER the event. There are two states, controlled by SET ON and SET NOON. When SET ON is in effect, DCL checks $SEVERITY at the end of each command. If there is an ON WARNING, ON ERROR or ON SEVERE_ERROR action defined, it will be taken if the $SEVERITY matches the condition.

 

Note that SET ON must be enabled BEFORE the command which is subject to the ON condition. Thus:

 

$ ON WARNING THEN WRITE SYS$OUTPUT "Warning"
...
$ SET ON
$ BACKUP ... whatever


$ ON ERROR THEN GOSUB HandleError
...
$ SET ON
$ BACKUP ... whatever


$ ON SEVERE_ERROR THEN EXIT
...
$ SET NOON
$ BACKUP ... whatever

 In the first example, any BACKUP status of WARNING, ERROR or SEVERE_ERROR will result in the string "Warning" being written and execution will continue.

 

In the second example, an ERROR or SEVERE_ERROR will branch to subroutine HandleError. At the first command in HandleError, $STATUS and $SEVERITY will reflect the results of the BACKUP command (or whatever command generated the error)

 

In the 3rd example, although there is an ON SEVERE condition enabled, the BACKUP command is preceeded with SET NOON which will disable the action, so execution will continue regardless. $STATUS and $SEVERITY will be set after the BACKUP command.

 

Also note that ON conditions are "one shot". Once it's taken, the ON condition will revert to the default, which is ON ERROR THEN EXIT. Simple example:

 

$ ty ERRWARN.COM
$ ON WARNING THEN GOSUB Warn
$ WRITE SYS$OUTPUT "Before first warning ",$SEVERITY," ",F$ENVIRONMENT("ON_SEVERITY")
$ junk1
$ WRITE SYS$OUTPUT "After first warning  ",$SEVERITY," ",F$ENVIRONMENT("ON_SEVERITY")
$ junk2
$ WRITE SYS$OUTPUT "After second warning ",$SEVERITY," ",F$ENVIRONMENT("ON_SEVERITY")
$ GOSUB GenerateError
$ WRITE SYS$OUTPUT "After error          ",$SEVERITY," ",F$ENVIRONMENT("ON_SEVERITY")
$ EXIT
$ warn:
$   WRITE SYS$OUTPUT "warning"
$ RETURN
$ GenerateError:
$ RETURN 2

 

 and the results:

 

Before first warning 1 WARNING
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
 \JUNK1\
warning
After first warning  1 ERROR
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
 \JUNK2\
After second warning 0 ERROR
%NONAME-E-NOMSG, Message number 00000002

 

 After the first warning condition, we see the message generated by the command itself, then the message from subroutine Warn. On return $SEVERITY is 1 - from $STATUS returned from subroutine Warn (implicitly that of the WRITE command)

 

After the second warning, we see the same message, but subroutine Warn was not invoked, so $SEVERITY is 0 from the generated warning. Although there is an active ON condition, it's at ERROR level, so not triggered by a warning.

 

We then see the ERROR generated, but never reach the next statement because the default ON ERROR THEN EXIT was triggered, so the EXIT was taken.

 

Sean, in order to show a problem with BACKUP setting $STATUS or $SEVERITY, your code must look like this:

 

$ SET NOON

$ BACKUP whatever

$ BackupStatus=$STATUS

$ SHOW SYMBOL BackupStatus

 

Note there cannot be any commands between the BACKUP command and the assignment of BackupStatus.

 

IFF your symbol BackupStatus doesn't match the most severe message generated by the BACKUP command, then you have something to report.

A crucible of informative mistakes
Sean OBanion
Occasional Advisor
Solution

Re: BACKUP 8.3 $SEVERITY not set to error

(Insert Homer Simpson's most profound D'OH!)

 

You are all correct: it's my thinking that gone wrong here.

 

Staring with a poor decision to not use the ON ERROR mechanism…

 

After actually thinking about what I was trying to do, and not coding first (yes, I know…) along with re-reading comments here, I have the procedure doing what I think it should.

 

And no, nothing is wrong with BACKUP.

 

Thanks for all your help!

Sean O'Banion


Well, technically, yes and no.