Date   : Tue, 10 Oct 2006 09:00:43
From   : jgh@... (Jonathan Graham Harston)
Subject: Re: How to *SPOOL result of *INFO?

>Message-ID: <4e728bf49cinfo@...>

Sprow <info@...> wrote:
>    Jonathan Graham Harston <jgh@...> wrote:
> > If you're into reprogramming your DFS EPROM, then with DFS 1.2x
> > changing the byte at &B994 from &AA to &60 disables the code that
> > changes the output stream with *FX3.
>
> You like living dangerously - surely FX3 is disabled for a reason? It's
> probably quite difficult to predict what might happen.

Writing to a file may result in the catalogue being loaded into
memory, and sometimes being updated and saved back to disk.

For example, when *SPOOLing, every 256 bytes the buffer is saved
to disk, and if the output file needs extending, the catalogue is
loaded into memory to attempt an extension.

If something is being displayed from a file action the display
depends on the catalogue that is in memory at that point.

For example, *INFO *.* displays information from the catalogue
that is in memory. *OPT 1,1 and then SAVE displays the file's
information from the catalogue in memory.

If you are SPOOLing, then these two processes can conflict.

For example, *SPOOL to a file, then do *INFO *.* The *SPOOL opens
an output file, which loads the catalogue into memory, alters it,
and then writes it out again.

*INFO *.* loads the catalogue into memory and the displays its
contents.

The spool system writes characters to the output stream and every
256 bytes saves the current buffer.

*If* the spool file needs extending, then the catalogue will be
loaded, altered, and saved. This means that the catalogue in
memory that *INFO *.* is displaying changes.

This is unlikely to be a problem if spooling to the same drive
that you do *INFO *.* on. It will be the same disk's catalogue in
memory. *INFO *.* will either have already outputted the
information for the spool file, or it will output the updated
information.

A problem occurs if you spool to one drive, and the *INFO *.* a
different drive. When the extend occurs (in the middle of *INFO
*.* operating), then suddenly a different disk's catalogue is in
the memory that *INFO *.* is stepping through.

This doesn't explain why *HELP DFS disables the spool output, as
*HELP doesn't access any disks. Typically, DFS disables spool
output for *all* output.

If you ensure that your spool file will never need to be extended,
then a new catalogue will not be loaded in the middle of it's
output. You can do this by presaving a file long enough not to
need extending.

When doing *INFO *.*, the maximum amount of data printed will be:

31 names formatted as "d.qwertyu l ff0000 ff0000 001010 002" plus
31 LF+CR sequences, 1*38, 78 bytes, &49A bytes. So,

    *SAVE file 0+500
    *SPOOL file
    *INFO *.*
    *SPOOL

should be safe.

> I agree it's not overly difficult to allow spooling from the FS if plumbed
> in from the beginning: it's mainly a workspace corruption thing, checking

Knowing that DFS did it, I worked it in from the beginning with
HADFS. All free space map information that is printed (that could
be spooled and so result in a different free space map being
loaded) is printed in an atomic operation.

Nothing gets corrupted, and the only oddity occurs if you are
spooling when doing *MAP. If the spool file gets extended, you end
up displaying the free space map loaded to extend the spool file.

Also, the "Can't extend" error closes any open SPOOL file if the
SPOOL channel caused the "Can't extend" error to avoid being
trapped in a continuous "Can't extend" loop.


--
J.G.Harston - jgh@...                - mdfs.net/User/JGH
Our chief weapons are 'who', 'ps -aux', 'kill -9', and a fanatical devotion
to 'reboot -q'.