🚀 go-pugleaf

In article <27A00A05_000735D8.009632ACBE1AF5C0$195_1@UK.AC.KCL.PH.IPG>, 
SYSMGR@IPG.PH.KCL.AC.UK (Nigel Arnot) writes:

>I have now found another funny: the same problem in reverse. A user ran
>a FORTRAN program that generates two output files: the first stays small,
>the second ends up at around 3000 blocks, both are opened 'NEW' (ie empty)
>and filled with sequential writes.
>
>Recently he noticed that the first file had been allocated with an initial
>size of 6000+ blocks. This was about two-thirds of his available disk quota,
>and also would have doomed the job (after a couple of days' crunching) because
>the second file would have run out of quota to grow into. I gave him more
>quota to avoid this, and the first file got truncated to about 20 blocks
>when the job finished.  I have never seen anything like this before VMS 5.5.

I have no opinion on the cause of this oddity, but wonder if the addition
of an explicit "INITIALSIZE=mmm,EXTENDSIZE=nnn" to the Vax Fortran OPEN
statement for the affected file might override it, reducing the need for a
quota extension (or at least letting the poor user use the extra space for
something other than a temporary scratch area).  If even this doesn't help,
the classification definitely becomes more "bug" than "feature".

-----------------------------------------------------------------------
George J Perkins    perkins@msupa.pa.msu.edu    gjperkins@fnal.fnal.gov