WRITE on the AUTOMATIC table - was: -RO causes an error

[John Esak]

George Simon wrote:

> Writes from auto processing have been disabled for over 10 years.
>

Hi George,

I'm not sure about the 10 years... but you're certainly right about the
WRITE in AUTOMATIC processing being disabled. At least, to a point. I think
it deservers some clarification, so I did some testing. To prove out what is
actually working (and not). Try this:

Build a screen in a test file that has a field 1 of say 2,.0 edit type. Then
put this as your AUTOMATIC table. Leave the INPUT table blank:

      if:
    then: 1="14";  WRITE;  end

Then go into the file using either dclerk or rclerk (rclerk, assuming you've
tokenized the AUTOMATIC table), and look at that screen which carries field
1.  As you down arrow through the records, you will see that they all have
"14" in field 1... even the unused records! Of course, this is just the
AUTOMATIC table doing what it _should_ do, i.e., making it *appear* as if
field 1 is equal to "14"... To see if field 1 is *really* being set to "14",
just hit B for Browse and look at field 1 on that display. You will see that
no field 1 has been *really* changed to "14". Every field 1 is whatever it
used to be. Untouched, even with the WRITE on the AUTOMATIC table.

Now, do this:

   dreport that_filename -fp "" -a -u

This will run dreport against all the records in that file and since you
have specified no OUTPUT table, the only one that will run is the AUTOMATIC
table. BANG! All the field 1's in that file are changed (really changed) to
"14".  So, it appears as if the AUTOMATIC table can write to the real fields
and this operation is stored.

NOTE: Even if there is some other OUTPUT table active, the AUTOMATIC table
still sets field 1 equal to "14" and it stays so written. At first, I
thought it was the action of the OUTPUT table that was finalizing the write.
In other words, the AUTOMATIC table assigned "14" to field 1, and the
END'ing of the OUTPUT table process caused this field to be written that
way. However, by running with -fp "", I think this eliminated that theory.

Ken or FP Tech, can verify whether I've gotten things correct or not.

John Esak

P.S. Obviously, *clerk would do the same thing given a chance. In other
words, if you assign something (like "14") to field 1 on the AUTOMATIC
table, and then physically press (U)pdate and then SAVE the record, the
assignment would stick. Again, you could verify this with the IUA Browse
which displays the contents of the fields unadulterated by the AUTOMATIC or
INPUT tables.