home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 19916 < prev    next >
Encoding:
Internet Message Format  |  1992-12-27  |  3.2 KB
  1. Path: sparky!uunet!news.claremont.edu!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: VAX c
  5. Date: 27 Dec 1992 07:41:27 GMT
  6. Organization: HST Wide Field/Planetary Camera
  7. Lines: 53
  8. Distribution: world
  9. Message-ID: <1hjmn7INN34t@gap.caltech.edu>
  10. References: <24DEC199220084219@spades.aces.com> <Bzt6EF.Est@dale.cts.com>,<1992Dec26.100030.299@rlgsc.com>
  11. Reply-To: carl@SOL1.GPS.CALTECH.EDU
  12. NNTP-Posting-Host: sol1.gps.caltech.edu
  13.  
  14. In article <1992Dec26.100030.299@rlgsc.com>, gezelter@rlgsc.com writes:
  15. >I will admit that the following solution is a bit of hitting a 
  16. >small ant hill with a large explosive, but ...
  17.  
  18. If memory serves, it's even worse than that!
  19.  
  20. >When the time expires, close the file. Then re-open it in append 
  21. >mode. This will ensure that all of your buffers are flushed out 
  22. >to the disk.
  23.  
  24. I tried that once.  Maybe it had to do with the way the file dealt with
  25. records, but what I ended up with with was a file that had *ONE* record per
  26. block.  Not what one would want.
  27.  
  28. Now, DEC support recommended an "undocumented and unsupported" routine.  I'm
  29. 99.9999999999999999999999% certain that this routine was one that returned the
  30. RAB associateded with a file id.  Given that, the worst that could happen if
  31. you tried to use it (i.e., ran the routine, then tried to do a SYS$FLUSH on the
  32. RAB at the address returned) would be that you'd get a status complaining about
  33. an invalid stream identifier (OK, OK, there's a [n infitesimal] chance that if
  34. the routine failed to work properly, it would return the address of SOMETHING
  35. that looked like a valid RAB, and who knows what would happen then?  But do you
  36. have any idea what the odds are against that?)
  37.  
  38. >If I remember correctly from the original post, the application 
  39. >in question is not a high bandwidth application. The periodic 
  40. >close/reopen cycle should not appreciably increase your CPU 
  41. >consumption.
  42.  
  43. CPU's not the problem here.  The problem is that every time you do it, you use
  44. up another block on the disk.
  45.  
  46. >I hope that the above is helpful. If I have been unclear, or if I 
  47. >can be of further assistance, please feel free to contact me via 
  48. >Email or phone.
  49.  
  50. Please note that I'm not trying to put Bob down;  his solution WILL work;  but
  51. it uses up lots of disk space.  The better alternative is to use the
  52. "undocumented and unsupported" function that returns the RAB associated with
  53. the file descriptor, and do a $FLUSH on that.
  54.  
  55. IMNSHO, there ought to be a documented and supported (though perhaps
  56. discouraged) way to get the RAB associated with a file descriptor [anybody from
  57. DEC listening?  You guys've probably got what you think is a good reason for
  58. not doing this:  care to share?])
  59. --------------------------------------------------------------------------------
  60. Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
  61.  
  62. Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
  63. understanding of astronomy is purely at the amateur level (or below).  So
  64. unless what I'm saying is directly related to VAX/VMS, don't hold me or my
  65. organization responsible for it.  If it IS related to VAX/VMS, you can try to
  66. hold me responsible for it, but my organization had nothing to do with it.
  67.