Ditto.  Would a workable middle ground be to provide YAM
(Yet Another Mode :) that explicitly performs the aforementioned
open and close?  That way we would have the benefits of the faster
listf, and still be able to see the EOF without accessing it via some
other mechanism (my old personal favorite was to use FCOPY:
FCOPY FROM=$NULL;to=whatever then perform the listf,2).

I've never checked, but how does FINFO(file,"EOF") calculate
the value it returns for a "growing" file?  I wouldn't think that
this patch would alter it's method, but stranger things.....

Regards,
Michael L Gueterman
Easy Does It Technologies
email: [log in to unmask]
http://www.editcorp.com
voice: (888) 858-EDIT -or- (509) 943-5108
fax:   (509) 946-1170
--

----------
From:  [log in to unmask][SMTP:[log in to unmask]]
Sent:  Tuesday, September 23, 1997 8:52 AM
To:  [log in to unmask]
Subject:  Re: [HP3000-L] LISTF,access - "feature" missing

__X___ Yes I rely on this undocumented "feature" of LISTF

______ No I don't need LISTF to update the EOF on disk

______ I don't know yet but I will get back to you.

Although I will be able to survive with out it, I must say that I like that
feature.  Not every programmer provides code to report the progress of his/hers
process and many times 'two' simple listfs will give me the needed feedback.
(which is even better than the situation in the MPE/V days, where one could see
the 'eof' being updated when an extent was posted to disc).