home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / vms / 20655 < prev    next >
Encoding:
Internet Message Format  |  1993-01-09  |  3.9 KB

  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!sgiblab!adagio.panasonic.com!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
  2. From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: Question about RMS and MSCP-pair [correction]
  5. Date: 9 Jan 1993 12:09:26 GMT
  6. Organization: HST Wide Field/Planetary Camera
  7. Lines: 58
  8. Distribution: world
  9. Message-ID: <1imf9mINNg7a@gap.caltech.edu>
  10. References: <9301051701.AA12189@uu3.psi.com>,<1993Jan6.094211.23666@news.th-darmstadt.de>
  11. Reply-To: carl@SOL1.GPS.CALTECH.EDU
  12. NNTP-Posting-Host: sol1.gps.caltech.edu
  13.  
  14. In article <1993Jan6.094211.23666@news.th-darmstadt.de>, sysgaertner@cygnus.frm.maschinenbau.th-darmstadt.de (M. Gaertner, FRM, TH Darmstadt, Germany) writes:
  15. >Well,
  16. >no I have seen a lot of replies to my message and they were very useful.
  17. >Some didn't get exactly my point, but that could have been me.
  18. >Ok, I agree with Jerry about the point of the copied data to the block with
  19. >forced error bit. This is how I understood the subject.
  20. >My claim was, that in my opinion the RMS overestimated the handling of the data.
  21. >Let's see,
  22. >the corrupted data may or may not have been copied to a clean, new and save
  23. >block with a bit set to indicate the unssave condition of the data.
  24. >Now any product (type, dump, edit etc.), when reading this block receives the
  25. >forced error flag condition back, instead of SS$_NORMAL (or such).
  26. >They then, due to the fatal bit, stop their work.
  27. >That's ok so far, no flame about that.
  28. >BUT WHY ISN'T RMS JUST RETURNING AN ERROR WITHOUT FATAL-BIT SET ???
  29.  
  30. Because, as far as RMS knows, the block contains gibberish, AND ANY FURTHER
  31. ATTEMPT TO READ THE FILE, EVEN AFTER YOU GET BACK TO THE GOOD BLOCKS, IS LIKELY
  32. TO RESULT IN SIMPLY MORE GIBBERISH!  A block of gibberish in the middle of a
  33. file is certainly serious enough to warrant being considered a fatal error.
  34.  
  35. >This, in my opinion, has the advantage, that the error-handler, if proper
  36. >programmed, can choose to run with the bad data or to quit. That's how
  37. >working with an error-condition is designed (should be!). A fatal error 
  38. >per se must always lead to a program-termination.
  39.  
  40. No.  You're misunderstanding the distinction between an exception and a fatal
  41. error.  Certainly an unhandled exception should cause image termination. 
  42. Processing of a fatal error return status from RMS is *ENTIRELY* up to the
  43. application.  The application looks at the return status and picks an
  44. appropriate course of action.  You don't simply get dumped back to the DCL
  45. level directly from the RMS routine.  If that were the case, then BACKUP
  46. wouldn't be able to copy the file.
  47.  
  48. >Sure, data integrity is a bit spoiled then, but why not let the user 
  49. >decide what to do with the data ?!
  50.  
  51. RMS lets you do exactly that!
  52.  
  53. >You see, I'm working at a site, where we have a lot of mechanical 
  54. >engineers as users and, beeing one myself, I know how *ignorant* they 
  55. >are about computers. And with the current handling, they can't restore 
  56. >the whole file without system-staff. So they miss X blocks instead of 
  57. >just one. Not everyone knows how to say $ DUMP/BLOCK and recover the 
  58. >rest of the data.
  59.  
  60. If they know that little about the operating system, then they can't be trusted
  61. to deal reasonably with the corrupted block.  You *CAN* read past the bad
  62. block;  but before the operating system lets you do that, you've got to prove
  63. to it that you know what you're doing.  What's do unreasonable about that?
  64. --------------------------------------------------------------------------------
  65. Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
  66.  
  67. Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
  68. understanding of astronomy is purely at the amateur level (or below).  So
  69. unless what I'm saying is directly related to VAX/VMS, don't hold me or my
  70. organization responsible for it.  If it IS related to VAX/VMS, you can try to
  71. hold me responsible for it, but my organization had nothing to do with it.
  72.