> From: Jeff Vance <[log in to unmask]>
> To: Nick Demos <[log in to unmask]>; [log in to unmask]
> Subject: Re: 1 Tbyte files and LISTF
> Date: Wednesday, March 25, 1998 8:30 PM
>
> On Mar 25,  1:51pm, Nick Demos wrote:
> > Jeff, I am not sure that I understand your three options correctly.
> > Are you talking about modifying the output format for LISTF for
> > all files in cases b and c?
>
> I guess I was vague in the distinction between the goals since
> several people have asked.
>
> a) states that LISTF,1 and ,2 should work exactly the same for all files
>    less than 4 GB (all files that exist today).
>
> b) states that LISTF,1 and ,2 will be different as of release x.y and
>    forces you to change as soon as you update to that release, regardless
>    of wheter or not you have any  large files are on your system
>    (not a popular choice so far).
>
> c) states that LISTF,1 or ,2 on a large file (> 4GB) should do something
>    to cause the application to "break" when extracting the EOF, LIMIT or
>    SECTORS fields.  The goal here is to prevent apps from using a
>    drastically wrong value for a file size.  This point has been the
focus
>    of much of the discussion.
>
> Most of the feedback favors a) combined with some version of c).
>
> > Anyway, some modification of scripts, etc., would have to be made
> > to get correct output for large files in any case.
>
> This is correct.
>
> > Use a marker, such as an asterik instead of a space before the
> > fields where the field would overflow....
> > The drawbacks are:
> > 1.  Scripts that were not changed would give eroneous results for
> >     large files.
>
> This is something that goal c) above is trying to address.  I think the
> best way to achieve this goal is to use an '*' in the fields that would
> otherwise overflow.  We would not write any numeric data to that field.
> This is approach favors programmatic LISTF,2 over interactive.  This
> seem appropriate to me: old programs can't react to the change but humans
> can.
>
> > 2.  The figures for large files would not be 100% accurate, only
> >     approximate.
>
> There are two kinds of accuracy issues: 1) the rounding error when
> expressing the size in megabytes (or GB, etc) rather than sectors.
> I am not really concerned about this error. 2) treating a number which
> is in MB or GB as if it was representing sectors.  This results in a hugh
> error and I am trying to minimize tha chances of this type of error.
> The '*' in the field rather than a number meets this goal.
>
> > However it would maintain backward compatibility in the sense that
> > if large files were not used, no change would be required.
>
> Based on feedback this is a requirement.

What is the relative importance of what one sees VS programs that parse
LISTF output?

It seems to me that LISTF is used more visually then programatically.

If this is the case a C (for times a hundred) or a
 --