I have not been following this thread in detail (due to the
overwhelming volume), so it is possible that I am repeating a point
that someone else has already made. Sorry in advance if that is the
case.

From what I have read the consensus seems to be that :LISTF,2 output
should be unchanged in the case where large files are not involved.
This insures maximum compatibility. Furthermore the consensus seems
to be if large files are involved it should "break" most
programs/scripts (eg: they should abort not report eroneous data).

If this is not the consensus then it is the general line of thinking
that I happen to agree with (therefore it must be correct ;-).

With that in mind, the main point(s) I would like to make are:

(1) It is not possible (IMO) to cause *all* programs to "break"
(with "break" defined to mean "abort" not "miscalculate") when it
encounters info for large files. No matter what data you put in the
:LIST output I can conceive of a program that will not abort.

(2) I think that one method of access the data is *much* more common
than any other method. It is my opinon that the vast vast vast
majority of all code parses the data in a method similar to the
following:

  * Extract columns x through y from the :LISTF output into some
    buffer.
  * Do some "editing" on the buffer (this is the dangerous
    part because depending on how sophisticated the "editing"
    is you may not be able to force the program to abort). Since (in
    this case) we are expecting a right justified number, and
    since the MPE intrinsics for converting from ASCII to Binary
    don't like blanks etc trim leading blanks.
  * Pass the edited buffer to some routine to convert it to a number.
    I think most code passes it to the BINARY or DBINARY intrinsic.

(3) The more sophisticated the editing done by the program on the
:LISTF,2 output, the more difficult it is to be sure that new output
will break it. However, the more effort the programmer put into
carefully editing the output before passing it to some intrinsic, the
more likely it is that they will actually report some kind of error
if they suspect something to be wrong with the data. So in a sense
the case we are worried about is the case where there is very little
editing (maybe just trimming leading blanks) and then passing the
output to BINARY. This seems to be solved by the sugestion to prepend
the unit of measure (eg: KB, MB, GB, or TB) to the the front of the
field.

                                 Scott McClellan
     ___   ___   _________       Hewlett-Packard
    /_ /| /_ /| /_______ /|      Commercial Systems Division
   |##| | ##| ||########| |      19447 Pruneridge Ave
   |##| |_##| ||##| |_##| |      Cupertino, CA
   |##|/__##| ||##|/__##| |
   |########| ||########|/       E Mail: [log in to unmask]
   |##| | ##| ||##| |            Phone : (919) 969-7870
   |##| | ##| ||##| |            Fax   : (919) 969-7871
   |##| | ##|/ |##|/
    --    --    --               Voice Mail : 447-6067