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.

Jeff Vance, CSY

--