home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 19953 < prev    next >
Encoding:
Text File  |  1992-12-28  |  2.3 KB  |  50 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!usc!sdd.hp.com!network.ucsd.edu!munnari.oz.au!uniwa!cujo!cc.curtin.edu.au!zrepachol
  3. From: zrepachol@cc.curtin.edu.au
  4. Subject: Semantics of append of files.
  5. Message-ID: <1992Dec29.004434.1@cc.curtin.edu.au>
  6. Lines: 38
  7. Sender: news@cujo.curtin.edu.au (News Manager)
  8. Organization: Curtin University of Technology
  9. References: <24DEC199220084219@spades.aces.com> <Bzt6EF.Est@dale.cts.com>,<1992Dec26.100030.299@rlgsc.com> <1hjmn7INN34t@gap.caltech.edu> <1992Dec27.100810.300@rlgsc.com>
  10. Date: Mon, 28 Dec 1992 15:44:34 GMT
  11.  
  12. In article <1992Dec27.100810.300@rlgsc.com>, gezelter@rlgsc.com writes:
  13. > In article <1hjmn7INN34t@gap.caltech.edu>, carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
  14. >> In article <1992Dec26.100030.299@rlgsc.com>, gezelter@rlgsc.com writes:
  15. ...
  16. > Carl,
  17. >  
  18. > I would be interested in hearing exactly what type of file that 
  19. > you had that problem of partial blocks with. I have been using 
  20. > this solution in a range of applications for about 15 years on 
  21. > both RSX and VMS and have never encountered the behavior that you 
  22. > describe.
  23. >  
  24.  
  25. Your example is a little bogus, as it only uses 1 block. The problem Carl
  26. refers to is a implementation detail to imcrease data integrity on an append.
  27.  
  28. Remember that the data will look like:
  29. ...[record-size]lastrecord in file....[-1]0000000... to the end of the block.
  30.  
  31. The end of file pointer should enable us to locate the [-1] record length
  32. ( no more data in this block ) word, but, where is the begining of the record?
  33. We will have to move part of it *AT LEAST* into a buffer so we can append to it,
  34. but we don't know how much. So we would have to block *ALL* access to the file
  35. while we start the append. In fact, we may have several records in our buffer,
  36. but how are we to know, unless we read ALL the file first...
  37.  
  38. The other way is to start the append at the begining of the next block, and
  39. stay away from the previous record. This would allow us to reliably interlock
  40. record access by locking a)the non-existant last-plus-one record in the previous
  41. block, and b) the record we are about to append, updating EOF, and deq'ing the
  42. record locks.
  43.  
  44. This is the origin of the puzzeling "I copyed 400 blocks of data from a bunch
  45. of files into one, and I've lost 40 blocks..." plea for help. The copy is a
  46. RECORD operation, and drops the empty space on the floor.
  47.  
  48. ~Paul
  49.  
  50.