HP3000-L Archives

April 1998, Week 2

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, 8 Apr 1998 13:47:57 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (119 lines)
At 10:19 AM 4/8/98 -0700, Jeff Vance wrote:
>Many thanks for all of the feedback and good suggestions! We have
incorperated
>many of these good ideas into the proposal below.
>Please notice the questions at the end!!
>
>Summary of changes:
>- listf,1 and ,2 will display all asterisks if the data doesn't fit a field
>- 2 new output formats, 10 ("Lsummary") and 20 ("Ldisc")
>- r/b and extent info dropped from ,20 output
>- room for one extra digit for record width
>- no commas in numbers (although I am considering user-defined outputs with
>  edits that would support commas)

I find all the changes listed so far are good.

>- k-bytes and M-bytes numbers are base 10 not base 2.

Uh, I think that's a mistake.  It will make the numbers come out rounded,
whereas using 1024 bytes as one KB will make the space allocated always be
an integral number of KB.

><<<<<<<<< Existing Output Formats >>>>>>>>>

No problem with what you propose for the old formats.

><<<<<<<<<<< New Output Formats >>>>>>>>>>>>>
>
>:listf @,10
>ACCOUNT=  SYS         GROUP=  OTHER
>
>FILENAME  CODE   ------------LOGICAL RECORD------------
>                   SIZE  TYP           EOF        LIMIT
>
>LARGE               80B  FA            500   1234567890
>LARGE1              80B  FA    12345678902  12345678902
>L2345678* AAAAA 999999W  FBxx 999999999999 999999999999
>SMALL               80B  FA            327          327
>
>
>:listf @,20
>ACCOUNT=  SYS         GROUP=  OTHER
>
>FILENAME  CODE   ------------LOGICAL RECORD------------ --SPACE (decimal)--
>                   SIZE  TYP           EOF        LIMIT    K BYTES  M BYTES
>
>LARGE               80B  FA            500   1234567890         40        0
>LARGE1              80B  FA    12345678902  12345678902  987654313   987655
>L2345678* AAAAA 999999W  FBxx 999999999999 999999999999 9999999999 99999999
>SMALL               80B  FA            327          327         27        0
>
>
>:listfile ./@,10 (or "Lsummary")
> PATH= /SYS/OTHER/
>
> CODE   ------------LOGICAL RECORD------------  FILENAME
>          SIZE  TYP           EOF        LIMIT
>
>           80B  FA            500   1234567890  LARGE
>           80B  FA    12345678902  12345678902  LARGE1
> AAAAA 999999W  FBxx 999999999999 999999999999 *L2345678
>           80B  FA            327          327  SMALL
>
>
>:listfile ./@,20 (or "Ldisc")
> PATH= /SYS/OTHER/
>
> CODE   ------------LOGICAL RECORD------------ --SPACE (decimal)--  FILENAME
>          SIZE  TYP           EOF        LIMIT    K BYTES  M BYTES
>
>           80B  FA            500   1234567890         40        0  LARGE
>           80B  FA    12345678902  12345678902  987654313   987655  LARGE1
> AAAAA 999999W  FBxx 999999999999 999999999999 9999999999  9999999 *L2345678
>           80B  FA            327          327         27        0  SMALL

Why do we need mode 10?  I have never understood the point behind having
mode 1 when mode 2 does everything mode 1 does with no discernable side
effects.  What's the point?  (The only possible reason I can think of is
that it takes a nontrivial amount of work to add up the extent sizes and so
when the disc space isn't needed, modes 1 and 10 may be more efficient than
modes 2 and 20, respectively.  However, I don't know whether this is the
case or not.)

>Questions:
>----------
>1) how should megabytes be rounded?
>   - mathematical rounding, ie. <= 4 round down, >=5 round up
>   - how should MB be handled for files less than 999 KB?
>     o apply same mathematical rounding?
>     o always report zero MB?
>     o always report 1 MB?

Personally, I don't see why we need to show MB at all.  Especially if MB is
defined as 10^6 bytes and KB is defined as 10^3 bytes, the numbers will be
the same (ignoring rounding up) other than dropping the last 3 digits of
the KB.  I think we should show only KB for the space, where KB is defined
as 2^10 bytes.  This will allow us to show exact disc space used without
any rounding, whereas using 10^6 or 10^3 bytes will always be rounded from
some multiple of the 4096 byte page size.

If there's some reason why we *really* need a 10^6 type MB then make it a
field which may have (or always has?) a floating decimal place, because it
will always be an approximation.  Small files will simply show more digits
to the right of the decimal point than large files.  Personally I think
this field isn't needed at all.

>2) is it acceptable to exclude R/B and extent info from the new ,20 format?

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