Re: Logical File Read Statistical Curiosities

HPO    28    1,829     511,652

The data here is 
(1) FILE then 
(2) average # reads per record per month since 98 06 09 creation date, 
obtained by dividing 
(3) # active records currently in the file into
(4) # logical reads.  

The big question is what is this data telling us - what is its significance - 
what can we learn from it?  Does high volume of logical reads imply a need to 
review whether we have good logicals or too many logicals?

There are some files whose statistics define a company more surely than what 
version we are running on, such as
AVM   1   964   11,851
GGM  2  1,466  26,778
ITH  1  640,099  2,342,349
LWK  67  79  53,307
RCM  38  69  26,458

For some files I would expect the number of records currently there to be 
about the same regardless of when we look at the file, such as
CMF  1   459,525   2,825,468
IIC     3           47         1,587
IIM   21     30,711   6,570,497
FLT    1     86,470     343,044
FRT   2   331,314   7,732,349
ILI      2     20,628     325,799
IWI     3    21,084      659,712
MBM  7    81,027   5,822,134
SIH    5      7,938      365,666
SIL     5     10,081     481,268
ZPA  14        477        67,670

Possibly some of these numbers might seem to be inconsistent, and a clue to 
something we might be doing wrong.  It seems extremely peculiar to me that 
the number of item warehouse combinations is not only about the same as when 
location is tacked on, but there are more IWI than ILI, implying that some 
kind of reorg is doing its job right for ILI but not for IWI.

For some files, if we have a seasonal business, or have had a recent purge, 
or significant alteration in actual customers or vendors, then the data might 
vary significantly due to that kind of pattern, influencing what we see in 
our snap shot, such as
CIC  10  19,289   1,911,960
ECH   7   2,638     190,838
ECL  26   9,276   2,417,439
ELA   5   5,467      285,861
FSO 4,943 4,756  235,101,721 
- this seemed to be the most volatile of all I checked
FMA 17  19,874  3,401,770
FOD   6   58,386  3,301,671
HPH   3       398      10,550
KFP  28    3,955   1,112,620
KMR  23   12,327  2,884,282
KRO   6     1,731      101,828
RAR  38         69         26,458

There are files that constantly show up on the reorg list, due to high 
volatility of deleted records needing removal, so their current number of 
records will be especially misleading, such as
GJW    1   9,871  142,537
VLA  159     160  255,064

I looked at statistics on HPO & some other files I expected might have high 
level of access due to the nature of our Manufacture Wiring Harnesses to 
Order with short lead times on 405 CD, but some of the numbers looked a bit 
weird or even bogus.  Initially I divided number of current active records 
into number of logical reads to estimate average rate of activity by file, 
but this can be misleading.

Remember another thread about the need to reorg files whose deleted records 
are not re-used by IBM, via SYS120 & IBM physical file member reorg?  Before 
I got that problem under control, I found files in which if you multiplied 
the number of deleted records by the number of bytes in each record, the 
total was an astronomical number rather in excess of the total amount of hard 
disk space. 

While looking at what our statistics are of the nature of what Marc called to 
our attention, I found several files in which I frankly do not believe what I 
am seeing.

First of all, when the number of logical reads is less than the number of 
actual records, that might be a clue that a file contains records we do not 
need, and that it is a candidate for analysis of what contents are actually 
there.

ESH  0   4,903   2,780
ESL   0   5,020     178
- in this latter case it had a total of 156 write operations & 491 physical 
file open & shut cases, in other words the grand total of all kinds of I/O 
operations is a small fraction of the actual number of records there - this 
calls into question the reliability of these IBM statistics, as if there is 
either some kind of operation that does not get captured by our OS/400, or we 
are not looking at actual counts, but rather calculated figures, whose input 
is not updated consistently, like what happens when the file is reorganized, 
or what happens when we do a version upgrade?  Perhaps some work file is 
created by copying some other work file & the statistics do not travel from 
the original to the copy.

IPH    ?   13    2 - this is another case where the number records outweighs 
the access methods

LCR   ?   10,967    0   - here is another file with only 145 physical open & 
shut - so how did the data get there?

SSH   ?   975   41 - another weirdo - 23 opens 29 closes 289 writes
When I ran the DSPFD statistics, it was on the eve of a big backup & I was 
doing *PRINT with *MBR so I would have some interesting stuff to look at 
while the system was tied up with SAVE 21 - there were no users on BPCS 
except for some other reports I was running off of current requirements, and 
several people who had left their work stations signed on at various menus, 
when they went home - anyhow, I thought this file only got updated during 
end-of-month.

Given the several cases of weirdo statistics, I do not know how much credence 
to grant these clues.
(a) perhaps the data is not a true count but calculated off of something, 
with an IBM fudge factor to avoid divide by zero
(b) perhaps some input to math is reset by reorg, or version upgrade, or 
colorful metaphor figuring out how to restore something that got broken, or 
the cross-environment links not defined properly, which is another unresolved 
problem on my plate.

DSPFD manual = CL Monster volume-3 Page P3-1858 --- gave me no clue to 
substantiate any of my notions as to where these anomolies might come from, 
so once again, do these statistical curiosities tell us anything useful that 
might help us manage our BPCS files?

Al Macintyre
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---