On Mar 25,  2:03pm, Gavin Scott wrote:
> Well, if we're primarily talking about :LISTF specifically (as opposed
> to :LISTFILE), then :LISTF already misses all non-MPE-named files in
> the group, so it's not neccessarily giving all the right data today.

This is true.  So does LISTFILE without the leading '/' or '.'.
Our LISTF decision to not show HFS named files was based on
minimizing the chances of breaking exsiting uses of LISTF.

> 1) What if :LISTF simply did not display large files?

I prefer to not have LISTF miss more files due to their size.  Also it
seem bizzare to do a LISTF big,2 and not see it but do a LISTF big,6
and it is shown.

> 2) What about having :LISTF display "maximum" values for large files,
> FILENAME  CODE  ------------LOGICAL RECORD-----------  ----SPACE----
>                   SIZE  TYP        EOF      LIMIT R/B  SECTORS #X MX
> BIG               128W  FB   999999999  999999999   1  9999999  *  *

Can't distinguish between a file with 9999999 sectors or more than that.

> 3) This problem was investigated and addressed years ago for the number
>    of extents, and max extents fields.  I think perhaps the most logical
>    (and relatively pleasing asethetically) thing to do is to simply
>    extend this to large files by displaying "*" for out of range values:
> FILENAME  CODE  ------------LOGICAL RECORD-----------  ----SPACE----
>                   SIZE  TYP        EOF      LIMIT R/B  SECTORS #X MX
> BIG               128W  FB    12345678          *   1        *  1  *

This is my preference today.  It eliminates the whole unit-of-measure
question, indicates to the human that info is missing for this field
(so try another LISTF format), and at the same time is a likely way to
"break" legacy:) apps that parse LISTF,2 for the EOF, LIMIT and
SECTORS field.

> On a related note, I'd like to see a :LISTFILE mode that displays file
> size in terms of bytes rather than sectors

I agree.

Jeff Vance, CSY

--