NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/os/vms/20655

Internet Message Format | 1993-01-09 | 3.9 KB

Path: sparky!uunet!haven.umd.edu!darwin.sura.net!sgiblab!adagio.panasonic.com!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
From: [e-mail] (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Question about RMS and MSCP-pair [correction]
Date: 9 Jan 1993 12:09:26 GMT
Organization: HST Wide Field/Planetary Camera
Lines: 58
Distribution: world
Message-ID: <[e-mail]>
References: <[e-mail]>,<[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <[e-mail]>, [e-mail] (M. Gaertner, FRM, TH Darmstadt, Germany) writes:
>Well,
>no I have seen a lot of replies to my message and they were very useful.
>Some didn't get exactly my point, but that could have been me.
>Ok, I agree with Jerry about the point of the copied data to the block with
>forced error bit. This is how I understood the subject.
>My claim was, that in my opinion the RMS overestimated the handling of the data.
>Let's see,
>the corrupted data may or may not have been copied to a clean, new and save
>block with a bit set to indicate the unssave condition of the data.
>Now any product (type, dump, edit etc.), when reading this block receives the
>forced error flag condition back, instead of SS$_NORMAL (or such).
>They then, due to the fatal bit, stop their work.
>That's ok so far, no flame about that.
>BUT WHY ISN'T RMS JUST RETURNING AN ERROR WITHOUT FATAL-BIT SET ???

Because, as far as RMS knows, the block contains gibberish, AND ANY FURTHER
ATTEMPT TO READ THE FILE, EVEN AFTER YOU GET BACK TO THE GOOD BLOCKS, IS LIKELY
TO RESULT IN SIMPLY MORE GIBBERISH!  A block of gibberish in the middle of a
file is certainly serious enough to warrant being considered a fatal error.

>This, in my opinion, has the advantage, that the error-handler, if proper
>programmed, can choose to run with the bad data or to quit. That's how
>working with an error-condition is designed (should be!). A fatal error
>per se must always lead to a program-termination.

No.  You're misunderstanding the distinction between an exception and a fatal
error.  Certainly an unhandled exception should cause image termination.
Processing of a fatal error return status from RMS is *ENTIRELY* up to the
application.  The application looks at the return status and picks an
appropriate course of action.  You don't simply get dumped back to the DCL
level directly from the RMS routine.  If that were the case, then BACKUP
wouldn't be able to copy the file.

>Sure, data integrity is a bit spoiled then, but why not let the user
>decide what to do with the data ?!

RMS lets you do exactly that!

>You see, I'm working at a site, where we have a lot of mechanical
>engineers as users and, beeing one myself, I know how *ignorant* they
>are about computers. And with the current handling, they can't restore
>the whole file without system-staff. So they miss X blocks instead of
>just one. Not everyone knows how to say $ DUMP/BLOCK and recover the
>rest of the data.

If they know that little about the operating system, then they can't be trusted
to deal reasonably with the corrupted block.  You *CAN* read past the bad
block;  but before the operating system lets you do that, you've got to prove
to it that you know what you're doing.  What's do unreasonable about that?
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: [e-mail] | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.