home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / vmsnet / internal / 1598 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  2.0 KB
  1. Path: sparky!uunet!stanford.edu!agate!spool.mu.edu!yale.edu!nigel.msen.com!emory!europa.asd.contel.com!darwin.sura.net!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!lll-winken!fnnews.fnal.gov!FNALF.FNAL.GOV!GJPERKINS
  2. From: gjperkins@FNALF.FNAL.GOV (George J Perkins)
  3. Newsgroups: vmsnet.internals
  4. Subject: Re: odd XQP behaviour
  5. Message-ID: <1e9gi4INN6p0@fnnews.fnal.gov>
  6. Date: 17 Nov 92 01:06:12 GMT
  7. References: <27A00A05_000735D8.009632ACBE1AF5C0$195_1@UK.AC.KCL.PH.IPG>
  8. Reply-To: gjperkins@FNALF.FNAL.GOV
  9. Organization: Fermi National Accelerator Lab
  10. Lines: 24
  11. NNTP-Posting-Host: fnalf.fnal.gov
  12.  
  13. In article <27A00A05_000735D8.009632ACBE1AF5C0$195_1@UK.AC.KCL.PH.IPG>, 
  14. SYSMGR@IPG.PH.KCL.AC.UK (Nigel Arnot) writes:
  15.  
  16. >I have now found another funny: the same problem in reverse. A user ran
  17. >a FORTRAN program that generates two output files: the first stays small,
  18. >the second ends up at around 3000 blocks, both are opened 'NEW' (ie empty)
  19. >and filled with sequential writes.
  20. >
  21. >Recently he noticed that the first file had been allocated with an initial
  22. >size of 6000+ blocks. This was about two-thirds of his available disk quota,
  23. >and also would have doomed the job (after a couple of days' crunching) because
  24. >the second file would have run out of quota to grow into. I gave him more
  25. >quota to avoid this, and the first file got truncated to about 20 blocks
  26. >when the job finished.  I have never seen anything like this before VMS 5.5.
  27.  
  28. I have no opinion on the cause of this oddity, but wonder if the addition
  29. of an explicit "INITIALSIZE=mmm,EXTENDSIZE=nnn" to the Vax Fortran OPEN
  30. statement for the affected file might override it, reducing the need for a
  31. quota extension (or at least letting the poor user use the extra space for
  32. something other than a temporary scratch area).  If even this doesn't help,
  33. the classification definitely becomes more "bug" than "feature".
  34.  
  35. -----------------------------------------------------------------------
  36. George J Perkins    perkins@msupa.pa.msu.edu    gjperkins@fnal.fnal.gov
  37.