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

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

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


Most of the applications I work with that have required that LISTF show a
reasonably accurate EOF were coded to use FCONTROL 6 every hundred or so
records written.  When MSG or CIR files are used, FCONTROL 6 is often used
after every read or write so as to avoid "bad variable block structure"
problems.  Thus, the change in LISTF ,2 won't affect these applications.

If LISTF ,9 (locks) will show the correct EOF, then my only concern is that
the change in behavior of LISTF ,2 may make working "legacy" (yuch! what a
word choice!) programs/applications/packages fail.  I guess that if
performance is a consideration, I'd rather have LISTF ,2 work the way it
has in the past, performance hit and all, and add a new LISTF (LISTF ,12?)
which looks like LISTF ,2 but doesn't update the EOF and has better
performance.  Compatibility with existing applications is my major concern.

John


At 03:01 PM 1997/09/23 -0700, Jeff Vance wrote:
>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
>
>
>
>
>
>
>
>--
>
>
--------------------------------------------------------------
John Korb                            email: [log in to unmask]
Innovative Software Solutions, Inc.

The thoughts, comments, and opinions expressed herein are mine
and do not reflect those of my employer(s), or anyone else.