RE: Speed in Reading -- RPG400-L

Thanks. I get all that.
I never said I would not use a new pool, just stated IBM's suggestion.
Perhaps this should be directed to IBM if their Help text is likely to be confusing.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Vern Hamberg
Sent: Tuesday, 8 June 2010 11:10 a.m.
To: RPG programming on the IBM i / System i
Subject: Re: Speed in Reading

Peter

Yes, it might do the trick. But the whole point of SETOBJACC is to
eliminate physical I/O, which is the slowest part of the process. If
things are being paged out, you are not eliminating physical I/O. And if
you need to repeatedly execute SETOBJACC, you are assuming that you need
to have more physical I/O.

I assure you, SETOBJACC is NOT meant to be run more than once for a
particular object.

BTW, I said in an earlier post that you should not use shared pools.
This is not true, but I think it is still a valid recommendation,
because, if you DO use shared pools, you have to turn off automatic pool
adjustments. This is because lack of activity in a pool (which is what
you want - NO jobs) will result in the pool being reduced in size to its
minimum setting. You could bump the minimum size to 100%, I suppose, and
then use a shared pool. Have never done that myself for this purpose.

Remember, you need enough main memory to hold these objects, and that
the memory used here will never be available for any jobs, otherwise. It
will be reserved, and is intended to be.

Here is a very comprehensive discussion - much more than the help text -
*http://tinyurl.com/2drpvmc

The connection between shared pools and performance adjuster came from
that article.

Mark W. mentioned SETACST MI instruction - I've used that, as well, and
there are things you can do with that, which can't be done with
SETOBJACC - the latter does a subset of the MI instruction, as I recall.
But you probably don't really need the full functionality of SETACST.

HTH
Vern
*
On 6/7/2010 4:20 PM, Peter Connell wrote:

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.