home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / vms / 20422 < prev    next >
Encoding:
Text File  |  1993-01-06  |  2.8 KB  |  53 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!math.fu-berlin.de!news.th-darmstadt.de!cygnus.frm.maschinenbau.th-darmstadt.de!SYSGAERTNER
  3. From: sysgaertner@cygnus.frm.maschinenbau.th-darmstadt.de (M. Gaertner, FRM, TH Darmstadt, Germany)
  4. Subject: Re: Question about RMS and MSCP-pair [correction]
  5. Sender: news@news.th-darmstadt.de (The News System)
  6. Message-ID: <1993Jan6.094211.23666@news.th-darmstadt.de>
  7. Date: Wed, 6 Jan 1993 09:42:11 GMT
  8. Reply-To: sysgaertner@cygnus.frm.maschinenbau.th-darmstadt.de
  9. References: <9301051701.AA12189@uu3.psi.com>
  10. Nntp-Posting-Host: cygnus.frm.maschinenbau.th-darmstadt.de
  11. Organization: Fachbereichsrechner Maschinenbau, TH Darmstadt, Germany
  12. Lines: 39
  13.  
  14. Well,
  15. no I have seen a lot of replies to my message and they were very useful.
  16. Some didn't get exactly my point, but that could have been me.
  17. Ok, I agree with Jerry about the point of the copied data to the block with
  18. forced error bit. This is how I understood the subject.
  19. My claim was, that in my opinion the RMS overestimated the handling of the data.
  20. Let's see,
  21. the corrupted data may or may not have been copied to a clean, new and save
  22. block with a bit set to indicate the unssave condition of the data.
  23. Now any product (type, dump, edit etc.), when reading this block receives the
  24. forced error flag condition back, instead of SS$_NORMAL (or such).
  25. They then, due to the fatal bit, stop their work.
  26. That's ok so far, no flame about that.
  27. BUT WHY ISN'T RMS JUST RETURNING AN ERROR WITHOUT FATAL-BIT SET ???
  28. This, in my opinion, has the advantage, that the error-handler, if proper
  29. programmed, can choose to run with the bad data or to quit. That's how
  30. working with an error-condition is designed (should be!). A fatal error 
  31. per se must always lead to a program-termination.
  32. Sure, data integrity is a bit spoiled then, but why not let the user 
  33. decide what to do with the data ?!
  34. You see, I'm working at a site, where we have a lot of mechanical 
  35. engineers as users and, beeing one myself, I know how *ignorant* they 
  36. are about computers. And with the current handling, they can't restore 
  37. the whole file without system-staff. So they miss X blocks instead of 
  38. just one. Not everyone knows how to say $ DUMP/BLOCK and recover the 
  39. rest of the data.
  40. Ok, let's stop here. I see, that my first guesses were correct about the 
  41. facts and that I did make the correct actions to restore the file.
  42. BTW, this fortunately happened on my home-system, and it only affected 
  43. my LOGIN.COM, but how many useful commands can you write in 512 bytes :-).
  44. See you,
  45.  
  46. -----------------------------------------------------------------------------
  47.  
  48.                       M. Gaertner
  49.                 TH Darmstadt, W. Germany
  50.          Rechnergruppe FB 16-Maschinenbau
  51.       SYSGAERTNER@CYGNUS.FRM.MASCHINENBAU.TH-DARMSTADT.DE
  52.       Phone: Germany, (0)6151/16 5145
  53.