HP3000-L Archives

October 2001, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"VANCE,JEFF (HP-Cupertino,ex1)" <[log in to unmask]>
Reply To:
VANCE,JEFF (HP-Cupertino,ex1)
Date:
Fri, 26 Oct 2001 20:09:18 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (58 lines)
...

> :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.

I think you already know this now, but after 5.5 exp 3, LISTF
and LISTFILE no longer open the files they are listing.
In earlier releases LISTF did an sm_open on all files being
listed (except formats 0 and 6).  I changed the code in
5.5 exp 3 to only sm_open the file for format 4 (file security).
The old LISTF implementation had the unplanned side effect of
posting the eof for any file listed that was also opened by
another process, due to calling sm_close.  So in the old version
of LISTF, the first time you listed a file opened for write
access, you'd see a stale eof from the label. The next time
you listed the file you'd see a refreshed eof since the prior
listf sm_closed the file and the eof was written to the label.

After 5.5 exp 3, LISTF grabs the eof for files being accessed
from internal data structures.  For files not begin accessed the
eof comes from the label.

...
> we presume that FINFO simply uses FLABELINFO())

True.

> 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.

Yes, on your OS version, FINFO and FLABELINFO get the eof from
the file label. In 7.0 there is a patch that makes them both work
like the current LISTF.

> 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.

Maybe FLABELINFO also sm_opens the file? If so that would
explain the behavior you're seeing.  Don't have time right
now to look at the code.

HTH,
 Jeff Vance, CSY

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

ATOM RSS1 RSS2