My point is that it isn't "spinning through the disk". Probably never touches disk at all. The index is most likely entirely contained in a memory page or two. That index is maintained within memory as a set of vectors in trees. The system need only make a few thunks through the vector map within memory to see that there is no index that matches your key.
From:midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of RPGLIST
Sent: Wednesday, January 23, 2013 10:41 AM
To: Midrange Systems Technical Discussion
Subject: RE: I/O count differences
I undestand that, I guess what I'm trying to determine how to evaluate the fact that its still taking resources and time (as minute as it may be) to spin through the disk.
> The system uses the index only on a no-hit. Never touches the data at all.
> -----Original Message-----
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of RPGLIST
> Sent: Wednesday, January 23, 2013 10:23 AM
> Subject: I/O count differences
> I need an explanation on this if someone would be so kind.
> When I chain to a file with a key and get a hit, I fully expect the
> I/O count to increase by 1, even though it is sort of doing a SETLL
> and then a READE within the chain process. However, whenever it
> doesn't find a record it shows no I/O count.
> I understand that since it didn't find a record it brough nothing back
> from the disk and therefore didn't increase the I/O count, but it
> certainly used resources to spin all the way through that drive
> disk....Is there anywhere that the system accoutns for this in the statistics?
> I see the same results when performing a SETLL, If %Equal, actually
> even if there is a hit I don't see an I/O count until the READE statement.
This mailing list archive is Copyright 1997-2013 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact