Re:
> Problem - A new data file ended up with a block of spoolfile data in it!
...

The short answer is "that's not supposed to happen".

The action of FCLOSEing the file after writing above the old
EOF (which is intially 0) should trigger a call to "fill_disc",
as can be seen from the following stack trace:


Break at: NM    [1] SYS a.0034f088 fill_disc
$3a ($6f) nmdebug > tr
     PC=a.0034f088 fill_disc
* 0) SP=41c693c8 RP=a.0057a738 fill_virgin_pages+$118
  1) SP=41c693c8 RP=a.003bd380 vsm_fill_disc_virgin+$388
  2) SP=41c69308 RP=a.00488634 sm_fill_disc+$44
  3) SP=41c68f88 RP=a.00488fcc sm_pin_eof+$f8
  4) SP=41c68f48 RP=a.005d8f10 sm_close_fd+$e9c
  5) SP=41c68e08 RP=a.00c2f9ac tm_close_common+$1a68
  6) SP=41c68b08 RP=a.0104bbcc tm_ord_fix_buf_disc+$1e4
  7) SP=41c67b48 RP=a.00b1c490 fclose_nm+$5e4
  8) SP=41c67a88 RP=a.00b1be78 ?fclose_nm+$8
       export stub: a.00ea8954 FCLOSE+$b8
  9) SP=41c67808 RP=a.00ea8868 ?FCLOSE+$8
       export stub: 870.0001fe38 my_fclose+$68
  a) SP=41c67748 RP=870.0002c3fc test+$2ad8
  b) SP=41c67508 RP=870.00035474 EX_PROGRAM

In addition to FCLOSE, an FCONTROL to "set the EOF" would also
cause fill_disc to be called.

fill_disc is used to fill the disc space between the old EOF
and the new (higher) EOF when the new EOF is about to be posted
to disk ... this is what should guarantee that you can't see
old data on disk.  The alternative would have been for MPE to
scrub the disk pages as they are allocated ... which is potentially
more expensive/slow than the current mechanism.


> Is it possible that when the file was created it picked up data from
> sectors on the disk (dirty data)?

As discussed, it *shouldn't* happen.

Another possibility is that something happened on top of your stack,
dirtying some stack pages.  Then, you called a routine that allocated some
local variables on those pages, *and* the routine has a path whereby it
writes some of those variables to disk without giving them a value
(i.e., so that they have the "uninitialized" value found on the stack).

I'm not sure what kind of event could lead to MPE processing a spool file
on your stack, however :)

Another possibility is a disk drive problem ... what kind of disk drive
is the file on?  What kind of interface?

> How can one be assured that a new file is actually empty/blank?

You shouldn't have to handle this ... but ... if you really want to
(as does IMAGE), you can do:

   fopen ( ..., 4, %104, ...)

   integer zero := 0;

   while not hit eof do
      fwrite (fid, zero, 1)

   fclose (fid, 1, 0);

Stan
--
Stan Sieler
[log in to unmask]
www.allegro.com/sieler/wanted/index.html

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *