home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / vms / 20388 < prev    next >
Encoding:
Text File  |  1993-01-05  |  1.6 KB  |  36 lines

  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!haven.umd.edu!decuac!pa.dec.com!engage.pko.dec.com!nntpd.lkg.dec.com!star.enet.dec.com!buda
  3. From: buda@star.enet.dec.com (Mark A. Buda)
  4. Subject: Re: Question about RMS and MSCP-pair
  5. Message-ID: <1993Jan5.191523.28086@nntpd.lkg.dec.com>
  6. Sender: usenet@nntpd.lkg.dec.com (USENET News System)
  7. Organization: Digital Equipment Corporation
  8. Date: Tue, 5 Jan 1993 19:15:40 GMT
  9. Lines: 25
  10.  
  11.  
  12. In article <1993Jan4.115621.29717@news.th-darmstadt.de>, sysgaertner@cygnus.frm.maschinenbau.th-darmstadt.de (M. Gaertner, FRM, TH Darmstadt, Germany) writes...
  13.  
  14. >What I don't understand is why the RMS then refuses to read the file 
  15. >where the forced error-block is in. It always returns the (correct) 
  16. >error (xxx, forced error flag set). So why does the revectoring take 
  17. >place? I don't care if the file is unreadable because of read-errors or 
  18. >forced errors. Or asked different, why isn't RMS showing the file as it 
  19. >is with a warning about the damaged block?
  20. >Can anybody give an explanation to me?
  21. >Oh, I know that revectoring bad blocks on the controller-level has it's 
  22. >advantages and I like the concept with the forced error flag BUT I don't 
  23. >like RMS's handling of these blocks.
  24.  
  25. RMS is not to blame, but the drivers that the I/O subsystem uses.  RMS gets
  26. an error back from the I/O subsystem and has to report it.  If you bypassed
  27. RMS an used QIO's, you would get the same result.  All you need to do is write
  28. to the block where the badblock is and the revectoring will occur and
  29. the problem will not be visiable any longer.
  30.  
  31.     - mark
  32.  
  33. buda@star.enet.dec.com
  34. ...!decwrl!star.enet.dec.com!buda
  35. buda%star.enet.dec.com
  36.