> From: Jeff Vance <[log in to unmask]>
>
>
> Hi all,
>
> For those of you that attended IPROF you know that we plan on supporting
> flat ASCII and NM KSAM files up to 1 Terrabyte in size in the first
> release of our Large Files project.  Subsequent releases will support
> bytestream and variable record files, with more file types added over
> time.
>
> This plan allows us to use all existing intrinsics unchanged since we are
> not increasing the max number of records in a file until *after* the
first
> phase.
>
> LISTF and LISTFILE are impacted in the first release of Large Files as
> follows (I will just refer to LISTF but in all cases I include LISTFILE
too):
>
>    LISTF,2 only allows 10 digits for the EOF and LIMIT columns and only 8
>    digits for the SECTORS column.
>
> However, for a terrabyte file we need 13 digits for the EOF and LIMIT
fields
> and 11 digits for the SECTORS field, assuming that we keep the units of
> measure as bytes for EOF and LIMIT (and we don't show commas).
>
> Now the point of this message:
>
>    What is more important to you and your customers (not mutually
exclusive
>    choices):
>
> a) guarantee 100% that all existing programs and scripts that process
>    LISTF,2 output will work correctly on all files <= 4 Gbytes.
>    However, for files larger than 4GB, these programs and scripts may
>    require modification.
>
> b) have LISTF,2 use the same output format for 1TB files as it does for
>    smaller files even if this breaks some existing applications working
on
>    less than 4GB files.  That is, force applications to change as soon as
>    large files become supported even if there are no large files on the
>    system.
>
> c) guarantee that any existing program/script that tries to process
LISTF,2
>    output on files larger than 4GB will return accurate results.  For
>    instance if this "old" program is adding up the EOF field it will get
an
>    addition error or abort or ??? when it encounters a large file.  That
is,
>    you don't want this program to silently "skip" (or add the wrong units
of
>    measure for) this large file when computing the total EOF across the
>    fileset.
>
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?

Anyway, some modification of scripts, etc., would have to be made
to get correct output for large files in any case.

My suggestion is as follows:

Use a marker, such as an asterik instead of a space before the
fields where the field would overflow.  The marker would indicate
that The number was to be multiplied by 100 to get the correct figure.
This, of course, means that all scripts, etc., would have to be
changed to handle large files, but if no changes were made, small
files would be still handled correctly.

The drawbacks are:

1.  Scripts that were not changed would give eroneous results for
    large files.

2.  The figures for large files would not be 100% accurate, only
    approximate.

However it would maintain backward compatibility in the sense that
if large files were not used, no change would be required.

Regards,

Nick

[log in to unmask]
My opinions are my own and I stand behind them.

Performance Software Group
Tel. (410) 788-6777 Fax (410) 788-4476