Re: Speed in Reading

Peter

Repeatedly running SETOBJACC will very likely cause worse performance, read that article that I gave the URL for - it's a lot more information than the help text.

And I have to agree with Charles - I think you are misreading the introductory material in the help text - it specifically says the command is used to bring AN object into main memory. As quoted,

"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."

Then it speaks of using the command several times -

"Repeated use of the command can cause a set of objects to be resident in a main storage pool."

It doesn't say to use the command repeatedly to keep a single object in the pool. It does say NOT to have any jobs running in that pool, for the reasons we have presented. IBM's suggestion is to use the command to get a SET of objects to be persistent in main memory.

What is the point of asking the system to do massive physical I/O again and again, to bring something into that pool, when the chances are that any or all of it gets paged out? It defeats the whole idea of this command, seems to me.

Eh?
Vern

On 6/7/2010 6:17 PM, Peter Connell wrote:

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.