I know that this subject is getting a little long in the tooth but before
it dies completely I wanted to address one feature that could possibly be
put into the ,11 format which we lost from the ,2 format when MPE/XL was born.
In Jeff's summary of changes he mentions:
>- r/b and extent info dropped from new ,11 output
I have no problem with losing the r/b and the max extents information since
this information is more or less useless and left for backwards
compatibility but I would like to cast a vote to output the number of
extents for a given file. This number is an '*' under MPE/XL and MPE/iX
when it is greater than 99. I can obtain the value by doing a ,3 or ,-3
LISTF but it is nice to see in a one line per file display like LISTF,2.
Anytime I see an '*' in this column while doing a LISTF,2 I usually do a
LISTF,3 to see how bad the number really is. This is exactly what Jeff is
talking about and serves as precedence for what we are trying to accomplish
for LISTF,2 to LISTF,11 functionality.
We currently have 3 files on our 918 which fall into this category:
ACCOUNT= PAUL GROUP= DDX
FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE----
SIZE TYP EOF LIMIT R/B SECTORS #X MX
MACITM70 PRIV 1664W FB 165173 391729 1 2149312 * *
ACCOUNT= TURBO GROUP= JUMBO
FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE----
SIZE TYP EOF LIMIT R/B SECTORS #X MX
ONEDET01 PRIV 1280W FB 1677600 1677600 1 16776016 * *
ACCOUNT= TURBO GROUP= SUBSET
FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE----
SIZE TYP EOF LIMIT R/B SECTORS #X MX
BADDB205 PRIV 512W FB 100 7500 1 30000 * 4
From this information we have no idea how many extents these files occupy
on the system. The LISTF,3 output can give you this information but try to
find it in the mess below:
********************
FILE: MACITM70.DDX.PAUL
FILE CODE : -401 FOPTIONS: BINARY,FIXED,NOCCTL,STD
BLK FACTOR: 1 CREATOR : **
REC SIZE: 3328(BYTES) LOCKWORD: **
BLK SIZE: 3328(BYTES) SECURITY--READ : ANY
EXT SIZE: 0(SECT) WRITE : ANY
NUM REC: 165173 APPEND : ANY
NUM SEC: 2149312 LOCK : ANY
NUM EXT: 1053 EXECUTE : ANY
MAX REC: 391729 **SECURITY IS ON
FLAGS : NO ACCESSORS
NUM LABELS: 1 CREATED : TUE, FEB 24, 1998, 11:58 AM
MAX LABELS: 1 MODIFIED: TUE, FEB 24, 1998, 1:24 PM
DISC DEV #: 1 ACCESSED: FRI, MAR 13, 1998, 9:28 AM
SEC OFFSET: 256 LABEL ADDR: **
VOLCLASS : MPEXL_SYSTEM_VOLUME_SET:DISC
FILE: ONEDET01.JUMBO.TURBO
FILE CODE : -401 FOPTIONS: BINARY,FIXED,NOCCTL,STD
BLK FACTOR: 1 CREATOR : **
REC SIZE: 2560(BYTES) LOCKWORD: **
BLK SIZE: 2560(BYTES) SECURITY--READ : ANY
EXT SIZE: 0(SECT) WRITE : ANY
NUM REC: 1677600 APPEND : ANY
NUM SEC: 16776016 LOCK : ANY
NUM EXT: 8196 EXECUTE : ANY
MAX REC: 1677600 **SECURITY IS ON
FLAGS : NO ACCESSORS
NUM LABELS: 1 CREATED : SUN, FEB 22, 1998, 6:37 PM
MAX LABELS: 1 MODIFIED: SUN, FEB 22, 1998, 8:10 PM
DISC DEV #: 1 ACCESSED: FRI, MAR 13, 1998, 10:10 AM
SEC OFFSET: 256 LABEL ADDR: **
VOLCLASS : MPEXL_SYSTEM_VOLUME_SET:DISC
FILE: BADDB205.SUBSET.TURBO
FILE CODE : -401 FOPTIONS: BINARY,FIXED,NOCCTL,STD
BLK FACTOR: 1 CREATOR : **
REC SIZE: 1024(BYTES) LOCKWORD: **
BLK SIZE: 1024(BYTES) SECURITY--READ : ANY
EXT SIZE: 7504(SECT) WRITE : ANY
NUM REC: 100 APPEND : ANY
NUM SEC: 30000 LOCK : ANY
NUM EXT: 256 EXECUTE : ANY
MAX REC: 7500 **SECURITY IS ON
MAX EXT: 4 FLAGS : NO ACCESSORS
NUM LABELS: 1 CREATED : TUE, NOV 11, 1997, 3:37 PM
MAX LABELS: 1 MODIFIED: TUE, NOV 11, 1997, 3:37 PM
DISC DEV #: 4 ACCESSED: FRI, MAR 13, 1998, 10:10 AM
SEC OFFSET: 256 LABEL ADDR: **
VOLCLASS : MPEXL_SYSTEM_VOLUME_SET:DISC
If you found 1053, 8196 and 256 you win!
These numbers can have a great impact on performance of a system. These
numbers are also a great plug for having one of the DEFRAG tools. :)
My understanding is that a structure is allocated for a file to hold
information for 20 extents and when this is full another structure is
allocated for the next 20 extents and so on. I believe that this extent
list is processed serially and when you have 8196/20 = 410 structures, it
can have a negative impact on performance whether you are accessing a file
serially or randomly.
Having a 4 digit number to display this information within a LISTF,11 would
be nice.
Does anyone else feel that this information should be included with
LISTF,11 or should I just deal with using LISTF,3?
Thanks for your time,
+---------------+
| |
| r | Ken [log in to unmask]
| e | http://www.adager.com
| g | Ken Paul Tel 208 726-9100
| a | Customer Support Fax 208 726-2822
| d | Adager Corporation
| A | Sun Valley, Idaho 83353-3000 U.S.A.
| |
+---------------+
|
