Re: despair
- From: AEF <spamsink2001@xxxxxxxxx>
- Date: Fri, 14 Sep 2007 10:40:23 -0700
On Sep 14, 12:46 pm, "David P. Murphy" <dpm_goo...@xxxxxxxxx> wrote:
On Sep 14, 3:45 am, Ron Johnson <ron.l.john...@xxxxxxx> wrote:
On 09/13/07 23:26, AEF wrote:
Is the same tape in the drive every day?
Don't know.
Are there any more BACKUP commands in the rest of the procedure?
No. In fact there is no DEALLOCATE command.
Obviously the author is comfortable with letting
the end of the job deal with cleaning up.
Does it matter? Defensive programming says you defend against
hardware glitches other people's mistakes.\
Yes. If the tape is never changed, you only have one backup at any
given time and it's on-site. If n tapes are rotated, you have n
backups, some of which may be offsite. What's the difference? n-1, of
course! :-)
I find it painfully ironic that the author took the mechanism
intended for error TRAPPING and used it instead for
error GENERATION. What the hell was he thinking?
I'll never know.
I find that BACKUP is very good at assigning W, E, and F to various
errors.
W is for errors like warning about files open for write that are being
saved anyway because of use of /IGNORE=INTERLOCK. Of course these
would be ignored by the default DCL error handler, (but I usually use
ON WARNING THEN GOTO _ERROR and make exceptions where needed).
E is for errors like files open for write and not saved, and
verification errors. (If you have to do a hot backup, you will likely
get a few spurious verification errors. The result is that the save
set is most likely okay. Of course, depending on this code snippet
(if /VERIFY were added to it) to ignore it is very risky as you might
get much more than the few verification errors expected on a hot
backup which may truly mean the save set you just made is truly
corrupted. Of course there's still some risk even with just a few
errors -- what to do depends on the situation. Someone needs to
inspect the log files in this case.
F is for truly fatal errors that are usually real show-stoppers.
Examples: not being able to write to tape, not being able to read the
tape during a verify pass, controller errors, parity errors, not being
able to write a file mark on tape, etc.
So the author of this bad code was apparently only worried about show-
stoppers. Probably he experienced errors due to files open for write
access and wanted the rest of the procedure to continue anyway (either
because he didn't realize the files weren't being saved or because
those files were not important to save), and this was the most
expedient way to deal with it. I'm not recommending this way of doing
things; I'm just trying to explain what I think the motivating factors
were. Of course incompetence and not-giving-a-s%%% are other possible
reasons! Maybe it was written by a BOFH!
P.S. Excellent poster, Brian!
ok
dpm
AEF
.
- Follow-Ups:
- Re: despair
- From: David P. Murphy
- Re: despair
- References:
- despair
- From: David P. Murphy
- Re: despair
- From: AEF
- Re: despair
- From: Ron Johnson
- Re: despair
- From: David P. Murphy
- despair
- Prev by Date: Re: despair
- Next by Date: Re: Will Linux bloat itself out of existance ?
- Previous by thread: Re: despair
- Next by thread: Re: despair
- Index(es):
Relevant Pages
|