home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!haven.umd.edu!darwin.sura.net!sgiblab!adagio.panasonic.com!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
- From: carl@SOL1.GPS.CALTECH.EDU (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: <1imf9mINNg7a@gap.caltech.edu>
- References: <9301051701.AA12189@uu3.psi.com>,<1993Jan6.094211.23666@news.th-darmstadt.de>
- Reply-To: carl@SOL1.GPS.CALTECH.EDU
- NNTP-Posting-Host: sol1.gps.caltech.edu
-
- In article <1993Jan6.094211.23666@news.th-darmstadt.de>, sysgaertner@cygnus.frm.maschinenbau.th-darmstadt.de (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: CARL@SOL1.GPS.CALTECH.EDU | 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.
-