Hi all,

The "LISTF,access" patch (MPEHXY8) is in 5.5 Express 3.  This patch contains
an enhancement to the LISTF, LISTFILE and LISTFTEMP commands where the
accessors of a file are displayed via two new formats - ,8 and ,9.

One of our astute testers (Rich Webber) discovered that the LISTF,access
patch does work the same as the old LISTF in regards to seeing
updated EOF information. Specifically, he could use the old LISTF,2 to
see the EOF of a particular file grows as writers appended to it.  Using
the new LISTF,2 he no longer sees the EOF grow until the file is closed.

Here is a description of how he used LISTF,2 to track a file's EOF: Session 1
is writing to a MSG file (note: the file type doesn't matter). Session 2
is doing interactive LISTF,2 of the same file.  He does multiple LISTF,2
and observes the EOF grow.  In fact, the first LISTF,2 shows the EOF at zero -
it isn't until he does a second LISTF,2 that he sees the EOF has increased.
This last point is important and discussed below.

Below I will provide a technical explanation of the behavioral differences,
but, cutting to the chase, I am very interested in learning if any of you
rely on *multiple* LISTF, LISTFILE or LISTFTEMP formats -5,-3,-2,-1,1,2,3,4,5
displaying the current EOF of a file *BEFORE* the file is closed by its
accessors.

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



Details:
--------

The "old" LISTF (LISTFILE and LISTFTEMP) sm_open'd each file listed for all
formats except 0 and 6.  Therefore it also sm_close'd each file after
displaying the data.  sm_close has a side effect of calling fill_disc in
certain situations, and fill_disc posts the EOF from an OS data structure
to the file label on disk.

So when our tester did his first LISTF,2 he saw the EOF in the label (on
disk) and sm_close ended up causing the EOF from the writer of the MSG file
to be written to the file label on disk.  When he did the next LISTF,2
he sees the just posted EOF from the label (although the EOF kept in memory
is probably larger) and again the sm_close posts the memory EOF to disk.
So each successive LISTF,2 shows the EOF posted by the previous LISTF,2.

When I re-wrote LISTF[ile|temp] for the accessors enhancement I eliminated
the call to sm_open (and thus sm_close).  There is a performance benefit to
doing this but my main motivation was to eliminate the possibility of LISTF
hanging on a file that was being diagnosed by the system manager. [ Note:
sm_open gets a few locks and will wait forever to do so, the new code
does nowait locks and iterates until it gets the lock or gives up trying.]

Historical note: when LISTF was first written for MPE XL there were no
sm_opens or sm_closes either.  This was strictly done for performance.
However, there were a few bugs with this approach and eventually we were
forced to put back the sm_open/sm_close.

For other reasons we are considering adding an option to sm_close so that
callers can cause sm_close to not post the EOF to disk.  If this option
were available, and LISTF still used sm_open/sm_close, I would have elected
to use this sm_close option because IMHO LISTF has no business updating
the file label just because someone else is writing to the same file.  This
is my opinion from a s/w engineer perspective.  However, if there are a
significant number of you who rely on this side effect of LISTF then I may
need to reconsider my implementation for LISTF,access.

A potential workaround for those of you needing this LISTF,2 "feature" may
be to use the new LISTF format 9 ("locks").  This format shows the current
record number for each process accessing the file.


Thanks in advance for your feedback,
Jeff Vance, CSY







--