In Response to:< Jeff Vance - 1 Tbyte files and LISTF>

Jeff,
    I think the solution might be a combination of items a) and c)
along the following lines:

    1.) b) should not be implemented as the ground rule is
         all current applications should function as they do now.

    2.) Enhance SYSGEN in the "io" or "resource" subcategory
         of the "misc" category to reflect the default "LISTF file size"
         (default to the current (max) size) and use an indicator
         that is a function of the powers of two(e.g. 16 or 24) or
         just a straight value indicating decimal place holdings
         (e.g. 10 for 4 Gb or 13 for 1 Tb).

    3.) Allow for a VAR to be set to allow the LISTF function to
         handle file sizes < or > the SYSGEN "LISTF file size".
         This will allow exception handling by specific situation
         and not be system wide.

    4.) The c) option would take the value of the SYSGEN entry
         and generate the LISTF format based on that value.
         If a file is larger than the SYSGEN "LISTF file size" or
         VAR value, the LISTF function should return an error,
         in which case the programmer can set the new
         VAR and modify any affected processes to account for
         the new format.

    This would allow all current processes to function as they do
now and be updated with the new VAR set as needed.
When all processes have been adjusted for the new
format the "LISTF file size" can be updated in the SYSGEN
and the VAR references removed at some future time if desired.


                                 Thank You......Eric Sand
                                                       [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.


        Your input will help us make design trade-offs on the LISTF and
LISTFILE
        command's support of Large Files.

        thanks,
        Jeff Vance, CSY

        --