But it would still do the trick.
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Tuesday, 8 June 2010 9:13 a.m.
To: RPG programming on the IBM i / System i
Subject: Re: Speed in Reading
Your presumption is incorrect...
Read the the first part of the help text...
"An object can be kept main storage resident by selecting a pool for
the object that has available space and does not have jobs associated
with it."
Also, in the document that Kurt provided a link too...
http://www-01.ibm.com/support/docview.wss?uid=nas1dc0a2297bdaefddb86256d6c0069907f
"If a private pool contains only the preloaded data, the data will
stay in memory until the object is explicitly purged (using SETOBJACC
), overlaid with another file as a result of another SETOBJACC (not
recommended), or the pool is cleared by using another new command,
Clear Pool ( CLRPOOL )."
"We recommend using a separate private pool. If you are going to use
the current job's pool, there is no guarantee that the data will stay
in memory. The data is not pinned in memory and can be stolen due to
page fault or other processing that requires storage pool memory. "
HTH,
Charles
On Mon, Jun 7, 2010 at 4:42 PM, Peter Connell
<Peter.Connell@xxxxxxxxxxxxxxxxx> wrote:
My presumption is that always running SETOBJACC prior to accessing the object in question would do the trick.
midrange.com
