Andy asks:
> 1. Since the file label is covered by the transaction manager, do
> I need to do a fcontrol 6?.

The file label would be protected by XM *if* it were getting changed by your
FCONTROL 2, which I'm not sure it is.  The main reason for having the file
label updated is if you're moving the EOF in the file.  If you're just
re-writing existing records, then there may be no need to ever update .

> 2.However, since I will have several processes reading the data which has
> been written, will I need to call fcontrol 6 to make sure these
> process can read all the data?

No, the FCONTROL 2/6 stuff should *only* have an effect on what you see if
the whole system crashes when the file is open for write access and is
actually being changed.  If the machine doesn't crash, your FCONTROL 2/6
calls will have no effect on the behavior of your application.

Stan suggested that if we still have some kind of file (RIO?) that can be
opened using "buffers" my multiple users without sharing the buffers (no
;GMULTI), then there might be a case where an FCONTROL would be needed to
let another process see the data, but I'm not sure that any such case exists
any more (and you'd have to try pretty hard to do it that way even if it's
possible).

Ok, so at this point I asked Stan whether there really was any difference
between FCONTROL 2 and 6 these days, and of course we had to go try it (on
6.0) and we didn't resolve the question as to whether FCONTROL 2 updates the
file label these days, but we did discover the most bizarre behavior from
FLABLEINFO.

So we open a file and write a record to it.

:LISTF now shows one record in the file (:LISTF now opens files and so gives
you the information that another program with the file open would see, *NOT*
what's in the file label!).  Fine and dandy.

Now we try :CALC FINFO("FILE","EOF") and a program that calls the FLABELINFO
intrinsic (these have the same behavior so we presume that FINFO simply uses
FLABELINFO())

Ok, we write a second record to the file and then use FINFO to ask for the
EOF.  The number comes back 1, so the FINFO is reporting the old
not-yet-updated value from the file label.

But then we call F[LABEL]INFO a second time, and now it shows 2!

After experimenting for a while, we decided that F[LABEL]INFO returns the
current (not updated) information in the file label, but as a *side effect*
calling FLABELINFO causes the file to be posted to disk (but *after* it has
already read the old data).  We have not looked at FLABELINFO to try to
figure out the mechanisms involved.

This is just too weird.

G.

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