× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



More importantly than what the program is reading and writing is what's being discussed here are logical read/write operations, not physical ones. The I/O count RPGLIST is looking at is very likely physical I/O not logical. You can use the performance tools to get both physical and logical I/O but not in the way I suspect is being used now. When the system gets ready to write to disk, it will be page at a time, not record/row at a time.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 1/23/2013 11:43 AM, Dan Kimmel wrote:
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.

-----Original Message-----
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-----
> From:midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of RPGLIST
> Sent: Wednesday, January 23, 2013 10:23 AM
> To:midrange-l@xxxxxxxxxxxx
> 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.
>
>
>
> --

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.