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:
Jeff Woods <[log in to unmask]>
Reply To:
Jeff Woods <[log in to unmask]>
Date:
Wed, 25 Mar 1998 19:33:32 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (71 lines)
At 02:03 PM 3/25/98 -0800, Gavin Scott wrote:
>On a related note, I'd like to see a :LISTFILE mode that displays file
>size in terms of bytes rather than sectors.

What Gavin said.

Unlike the changes being discussed to LIST[ILE} mode 2's output format for
very large files, a new LISTF[ILE] mode has no compatibility issues other
than being clear to those using it.  If a new mode similar to mode 2 is
created, I suggest it be use units of KB, MB, GB, TB, PB, XB and so on as
needed.  (Is that looking far enough ahead? ;)  Since the allocation of
disc space is always in an integral multiple of 4KB, there is no need to
ever use "B" as a unit.  The units should all be powers of 1024 (and hence
the letter should be capped).  And I don't care is LISTF has the new mode.
If anything, I think new modes should *not* be added to LISTF as folks
should be encouraged to use LISTFILE.

:listfile ,2
ACCOUNT=  SOME        GROUP=  GROUP

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

KILOFILE          128W  FB        1255       1255   1     1264  1  *
MEGAFILE         1024W  FB      364147    1880637   1  2913184  6  *

Perhaps the new mode will be "22".  At least it would be easy to retrain my
fingers.

:listfile ,22
account=  some        group=  group

filename  code  ------------logical record-------  --space---
                  size  typ        eof      limit    bytes mx

kilofile          128W  FB        1255       1255    316 K  1
megafile         1024W  FB      364147    1880637    711 M  *

BTW, note that I deleted the blocking factor and number of extents fields.
I find them to be of little use these days.  If one needs them, they are on
the detailed output format.  Also, the only use I see for the MX column is
to indicate if the file must be in a single extent or not.  Some simple
convention for indicating that bit of info is all I think is useful in the
#X and MX columns.  Perhaps we can use the extra columns to expand some of
the other fields, perhaps EOF, LIMIT or BYTES.

And while some hypothetical programmer is in there and I've got my wishing
hat on, downshift or mixed-case the heading...  perhaps even the file
names.  It's my opinion that lower case and mixed case text is easier to read.

P.S.  I prefer the convention of K=1024, k=1000, M=K^2, m=k^2, etc.  I also
favor a convention that B=bytes and b=bits.  An example: "I downloaded 23MB
over my 28.8kb/s modem."  where "MB" is read "megabytes" and "kb/s" is read
"thousand bits per second", which happens to be different than "kilobits
per second", although I admit I would often leave off the "/s" and "per
second" units on the modem and even cheat and allow "kb" to mean "k-baud",
which though technically inaccurate is very practical in common usage.  So
I'm not 100% consistent.  Oh well.  :)

P.P.S.  Hmmm... It never occurred to me before what the company name
"Exabyte" means.  Interesting....  :)
--
Jeff Woods
[log in to unmask] at Tivoli Systems
[log in to unmask]   at home  [PGP key available here via finger]

Haiku by Rahul Sonnad:
   There is a chasm
   of carbon and silicon
   the software can't bridge.

ATOM RSS1 RSS2