Look-aside buffer or look-aside map is what I understand to be the common computer science term for the memory vector that maps virtual addresses to actual memory address or disk sector. Any reference to a virtual memory address requires the processor to access the map and resolve the pointer to a physical memory location, paging in from disk if necessary.
As I understand it, because of the huge size of virtual memory addresses in IBMi single-level storage, new objects are allocated addresses after the last used address; there always seems to be more. However, I have heard of instances where all the addresses are exhausted. In that case, the code that assigns addresses to new objects has to go through some extra steps to find an available address. The OS keeps track of available addresses, of course. Still there's extra steps. As I recall, newer versions of the OS have done a better job of keeping track of available addresses. I vaguely remember this feature being touted in the release notes of one of the operating system releases. My memory is so vague, though, that it may have been V3R2, but I think it was something more like V5R2. In any case, I remember that prior to the new code, such a situation really slowed down new object creation and deletion.
In this case, we have an old version of OS and we have a system that has experienced a high rate of new object creation for a long time as new objects are created each time QTEMP is built and loaded with a bunch of objects. If the situation is as I describe, it would be coincident to Larry's upgrade and nothing to do with the new disks, cards and memory at all.
What would Larry have to do to have virtual memory addresses reassigned or otherwise reorganize what I have called the look-aside map? I thought RCLSTG would do it, but I'm a theorist not a systems guy.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, February 28, 2013 11:07 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: qtemp performance oddity.
On 28 Feb 2013 08:02, Dan Kimmel wrote:
RCLSTG is probably the answer; whatever you can do to rebuild the
look-aside map. All the QTEMP stuff goes in a separate range of
single-level-storage addresses, because when the job ends all the
memory and disk sectors go right back into the available pool.
Adding the extra memory may have spread the look-aside map into a
place where it isn't efficient.
Except what the RCLSTG will do if\for including a refresh of the *DBXREF, I do not expect that the RCLSTG request would assist.
I am not sure to what a "look-aside map" refers, but I doubt the RCLSTG will change whatever it is.
The QTEMP library, while its name might imply "temporary", is not temporary storage. The external objects in QTEMP are also not created with temporary storage addresses. Those objects are permanent objects in the address range of permanent objects. Besides, the reclaim storage only processes the permanent storage directory, so if the QTEMP and its objects were in the temporary storage directory, they would never be visible to the Reclaim Storage request. AFaIK the reclaim storage does nothing about permanent\temporary address range location, nor /where/ objects and data reside. The primary functions of RCLSTG are ownership recovery [every permanent object must have an owner; e.g. QDFTOWN], context recovery [assignment to permanent objects incorrectly found out of a context; aka library, or similarly a directory], destroying objects with invalid object types and orphan objects that are not data and for which no parent was created for its re-association, and damage notification, plus there are various other /component-specific/ actions that typically refresh their views of what is actually available on the system. The RECLAIM MI instruction basically starts multiple LIC tasks to generate object lists from subsets of the permanent storage directly.... and each object list is passed to the OS to perform the aforementioned work [i.e. the "primary function" of the reclaim].
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
