home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / vms / 20404 < prev    next >
Encoding:
Internet Message Format  |  1993-01-06  |  1.6 KB
  1. Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsm!cbnewsl!att-out!rutgers!spcvxb!terry
  2. From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: Question about RMS and MSCP-pair
  5. Message-ID: <1993Jan5.211713.4822@spcvxb.spc.edu>
  6. Date: 6 Jan 93 02:17:13 GMT
  7. References: <9301051405.AA16112@uu3.psi.com>
  8. Organization: St. Peter's College, US
  9. Lines: 21
  10.  
  11. In article <9301051405.AA16112@uu3.psi.com>, leichter@lrw.com (Jerry Leichter) writes:
  12. > By the time you get a "forced error", the data is gone.  The forced error
  13. > indicator is set on the REPLACEMENT block, not the original one, and I don't
  14. > believe the corrupted data, such as it was, is even copied into the block.
  15.  
  16.   It's implementation-specific, according to the MSCP architecture spec.
  17. There is no reasonable reason to copy the data in the case of an uncor-
  18. rectable error. However, some of the controller-based BBR implementations
  19. use a common code path with the correctable error / revector code and have
  20. a flag to say whether or not the forced error flag should be set. These
  21. implementations do in fact preserve the data, although it is certainly not
  22. the _correct_ data.
  23.  
  24.   BTW, the "forced error flag" is set by computing the CRC of the new block
  25. and writing it out complemented. Just a useless tidbit of trivia (unless you
  26. are going to physically talk to a drive with a controller of your own design
  27. 8-).
  28.  
  29.     Terry Kennedy        Operations Manager, Academic Computing
  30.     terry@spcvxa.bitnet    St. Peter's College, Jersey City, NJ USA
  31.     terry@spcvxa.spc.edu    +1 201 915 9381
  32.