Jeff Vance writes:
> 3. How about "RecSiz" for the record size field, or will this become
> the MPE equivalent of unix's "creat" controversy?
We wouldn't *call* a routine named RecSiz(), so there should be
no controversy. (Notice the operative word "should." ;)
> 4. No headers in the catalog. I'd really prefer to spend the time getting
> user-defined outputs and/or let LISTF "call" a script for each file
> to get you commas, etc. in the output. Does anyone remember when
> Master/3000 started using the message catalog? Performance suffered.
Heck, I don't even know what Master/3000 is!
Very much as an aside, if further use of the system msg catalog
is reluctant for performance reasons, is there any thought (gulp)
to converting to NLS?
> 5. No ",", "+", etc. in the header. See 4, and I think the header is
> slightly messier. I could be convinced otherwise, and I appreciate the
> motivation.
I understand.
> One problem I have is that we talk kilo, mega, giga as 2**10,
> 2**20, 2**30, etc, yet we want to view a base 10 number, like EOF, as
> kilo, mega or giga bytes by counting groups of three digits. This gets
> more confusing when applied to the "Disk Usage" column since the displayed
> value is in KB (base 2).
I don't find this confusing at all. The *number*, as displayed,
is a base-10 value, so commas are appropriate. (Oddly, this does
not hold true for a "decimal" point.) It's only when we see this
comma as a conversion for kilo, mega, etc. that there's trouble.
That is,
5000 MB == 5,000 MB == "5 thousand MB"
but
5000 MB != 5 GB
> Again, user-defined output obviates the need.
Okay.
> 6. User will just have to know what KB means in the disk usage column.
Not unreasonable. (If NO units were specified, long-time users would
likely assume sectors, and new users would likely assume bytes.)
> 7. Disc vs. Disk? HP officially replaced "disc" with "disk" many years
> ago. Notice the DISKUSE command? (and the DISCUSE UDC in hppxudc.pub.sys:)
> I don't care that much but I chose disk based on current HP convention.
Tough call. Official or not, "DISC" is still very much a part of the 3000.
But you're right; "Disk" *is* the proper spelling.
> 8. Added back number of extents without truncation. This field can hold
> a max of 16 bits (unsigned) which implies I need 5 numbers plus a space.
Good idea. Well-reasoned argument, Ken Paul!
[snip]
> :listfile ./@,11
> PATH: /A2345678/OTHER/
>
>Access FCode RecSiz Type EOF File Limit Disk Usage Exts Name
> ERWS ----- ------ ---- ------------ ------------ --------KB ----- -----------
> R 1 BA 12234 1234567890 12234 102 BYTEStream
> R 80 FA 500 1234567890 40 1 LARGE
> RW 80 FA 12345678902 12345678902 987654313 8 LARGE1
> W NMPRG 256 FB 99999999999 999999999999 9999999999 99999 L2345678901
> W 4096 FAO 1122 2233 444 14 LOGFILE
> R 256 VAM 222 3333 3333 22 MSGCOPY
> E OUTSP 1008 VACS 222 222 12345 33 SpoolFile
> S 80 FA 12345678902 12345678902 987654313 1422 STORE1
>....:....1....:....2....:....3....:....4....:....5....:....6....:....7....:....
Hmmm. The "*" indicating access currently shows here---------------^
just to the left of the filename. I suspect further that the Access
column is cross-referenced with the filename both ways in actual use.
That is, BOTH of the following thoughts are used:
[Looking at the filename, then across to the Access indicator]
"Is file LARGE being accessed?"
[Looking at the Access indicator, then across to the filename]
"Look! File LARGE is being accessed!"
Any chance of moving the Access column next to the filename?
--Glenn Cole
Software al dente, Inc.
[log in to unmask]
|
