HP3000-L Archives

March 1998, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Gavin Scott <[log in to unmask]>
Reply To:
Gavin Scott <[log in to unmask]>
Date:
Wed, 25 Mar 1998 14:03:54 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (70 lines)
Scott writes:
> 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.

Ditto.

> 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.

Sounds good to me.

> 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).

> 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.

Well, if we're primarily talking about :LISTF specifically (as opposed
to :LISTFILE), then :LISTF already misses all non-MPE-named files in
the group, so it's not neccessarily giving all the right data today.

Some possibilities:

1) What if :LISTF simply did not display large files?

This might be a problem for programs that use :LISTF to determine whether
a files exists, but you have the same problem today with POSIX named files.
Programs that don't know enough to use the new :LISTFILE modes (and thus
may not be compatible with the new file type) won't know that they exist.

2) What about having :LISTF display "maximum" values for large files,
   similar to the way that most calculators return 9.999999E99 for all
   "large" or infinite results?

FILENAME  CODE  ------------LOGICAL RECORD-----------  ----SPACE----
                  SIZE  TYP        EOF      LIMIT R/B  SECTORS #X MX

BIG               128W  FB   999999999  999999999   1  9999999  *  *

3) This problem was investigated and addressed years ago for the number
   of extents, and max extents fields.  I think perhaps the most logical
   (and relatively pleasing asethetically) thing to do is to simply
   extend this to large files by displaying "*" for out of range values:

FILENAME  CODE  ------------LOGICAL RECORD-----------  ----SPACE----
                  SIZE  TYP        EOF      LIMIT R/B  SECTORS #X MX

BIG               128W  FB    12345678          *   1        *  1  *

thus indicating that one needs to use the appropriate new :LISTFILE
mode to see the accurate data.

On a related note, I'd like to see a :LISTFILE mode that displays file
size in terms of bytes rather than sectors.  A 256 byte "sector" has
no meaning in todays world.  Disk drives no longer use 256 byte sectors,
and MPE allocates disk space in 4096 byte pages (didn't you ever wonder
why the 1-9 sector row in ":DISCFREE A" is always zero? :-)

  0 BLOCK(S) OF      1-     9 CONTIG. SECTORS =          0 FREE SECTORS.  0%
517 BLOCK(S) OF     10-    99 CONTIG. SECTORS =      19552 FREE SECTORS.  1%

G.

ATOM RSS1 RSS2