Error on BACKUP recording pass

[Antoniov.]

Chaim,
I guess you can issue the command SET FILE *.*;* /NOBACKUP before start backup.

Antonio Vigliotti

[Chaim Budnick]

YEHBUT !!

That will only work for the files that are there just before I start the backup. It will NOT affect any files created while the backup is running! From what I have seen during the day there are files being created/deleted almost every two minutes!

In the meantime I have added an /exclude for these files, but I'd like a better solution.

[Antoniov.]

Chaim,
may be stupid but ...
you could use /BEFORE qualifier as follow exaple:
$ NOW=F$CVTIME("";"ABSOLUTE")
$ BACKUP/BEFORE='NOW'/CREATED ....
In this way all files created after backup started are ignored (I hope).

Antonio Vigliotti

[Jan van den Ende]

Antonio,

"I guess you can issue the command SET FILE *.*;* /NOBACKUP before start backup.
"
... which still leaves the chance of entering new files between that command and the moment that the dir scan of backup reaches that dir.

Chaim,
the solution to this problem is a multiple ON..

You have now: ON ERROR THEN GOTO ..., which makes your procedure go to the error label and do whatever commands are there.

What WE do for situations like this:

$ ON ERROR THE CONTINUE
$ ON SEVERE_ERROR THEN GOTO ...

This makes a difference between "-E-" errors, like deleting a file between finding it in the scan, and processing during the actual backup, the recording pass, or the verification pass.
The "-F-" errors ( F for fatal, aka SEVERE ) are things like tape errors (position loss, for any of various reasons).
This way Backup -DOES- report the -E- errors, but continues with the rest of the job, however, anything seriously enough wrong to be -F- error (alas, on SCSI tape that includes a simple parity error!!) WILL give control to whatever you specified as error handling.


hth.

Cheers.

Have one on me.

Jan

[Bojan Nemec]

Chaim,

As you are not doing an image backup the /exclude will be yust fine. You can implement also Jans suggestion which will report only fatal errors.
Another possible way is to move the temporary directory out of the backup path.

Bojan

[Chaim Budnick]

I really really appreciate all of the replies!!!

I am NOT certain that trapping ONLY the severe errors is enough.

The error routine basically just sends a mail to our support center that there occurred an error during the backup routine. This mail is monitored by NON-VMS people. If they see an error then they tell me and I go in to see what actually happened. If no mail is received we basically assume, perhaps incorrectly, that everyting ran as expected without any problems.

The routine also sends a mail on completion, so that we know that the routine ran!

Chaim

[Bojan Nemec]

Chaim,

You can trap both types of errors. Then you can decide if you can ignore an error or not.

Bojan

[Jan van den Ende]

Chaim,


The error routine basically just sends a mail to our support center that there occurred an error during the backup routine. This mail is monitored by NON-VMS people.


So, now HERE is where YOU will need to dicide WHETHER you also want a report of the "-E-" errors!

If you do the ON ERROR THEN CONTINUE thing,
then, first thing after the normal ending of your Backup command, catch the value of $SEVERITY in a symbol of your own.
It WILL hold the severest message level encountered, ie, "1" for SUCCESS only if NO messages, "3" for -I- if ONLY Informationals, "0" for -W- if nothing more serious than Warnings, "2" for -E- if Errors but NO fatals, and "4" for -F- at any Fatal.

So, if you want to get MAILed in case of errors also, then GOSUB a MAIL-sending routine, and then continue normal processing.
(and of course at Fatal you have jumped this, and you do any processing necessary in that case)

hth

Cheers.

Have one on me.

Jan

[Antoniov.]

Chaim,
if you ignore file created after backup started (as I previous posted) you don't meet this error.

Antonio Vigliotti

[Wim Van den Wyngaert]

We do "set noon" and check if the status is a well known one. Well known are :
%X00000001|WMS_I_BCK_V4>END - Save Set is Terminated
%X10000001|WMS_I_BCK_V4>END - Save Set is Terminated|Post_Proc
X10A38410|WMS_W_BCK_V4>INFO - Open Files During Backup
%X10A3824A|WMS_W_BCK_V4>INFO - Open Files During Backup
%X10A38400|WMS_W_BCK_V4>INFO - Some Files Not Found During Backup
%X10A3800A|WMS_W_BCK_V4>INFO - Some Files No More Present For Write Backup Date
%X00038150|WMS_F_BCK_V4>ABORT - Something Wrong In Backup Command Line
%X00038098|WMS_F_BCK_V4>ABORT - Something Wrong In Backup Command Line
%X10A388A8|WMS_W_BCK_V4>INFO - Open Files During Backup(retries)

[Uwe Zessin]

Jan,

>$ ON ERROR THE CONTINUE
>$ ON SEVERE_ERROR THEN GOTO ...

have you tested this or know since when did it start to work? As far as I can tell, only the last "ON" is being used - one does not get a per-severity ON.

[Jan van den Ende]

Uwe,

how should it NOT work?

Try the logic:

ON WARNING -- traps any message of level Warning or more severe

-- then

ON ERROR -- traps any message of level Error or more severe
-- that means, level Warning is not influenced

-- and then even further

ON SEVERE_ERROR -- traps Severe (or Fatal) errors
-- leaving Error and Warning levels uninfluenced.

Until your question I never even gave it much thought, just used it, and I remember only one (evident) issue with it:

ON ERROR _does_ overrule ON SEVERE_ERROR

so the order is important!


-- I cannot remember ever having read or being taught so, but _IF_ this should NOT be the way it is implemented, then I guess I must have been SOOO lucky, I should have bought a lottery ticket instead of building this "construct" (quite a heavy name for two lines of code!)

fwiw

Cheers.

Have one on me.

Jan