Re: SETOBJACC Was: SSD Best practices

To expand a little, I believe this should not be a shared pool - I don't remember the reason, it's been a decade since I looked at this, at least. Maybe easier maintenance is the main reason.

And it should have no work done in it, so that there is no reason for paging at all. It's best use is to be a static pool. Anything in memory is available to all processes, as Chuck said.

I think it is suggested to load up memory early in a day or some other time period, when no work is done - maybe do a CLRPOOL first, as well.

Drawback? You do end up with a part of memory that isn't being adjusted. So you do need enough memory to be able to reserve this. Sort of like reserving some DASD for a special purpose - I know, probably a distant cousin as to concept, but it comes to mind.

HTH
Vern

On 2/15/2013 3:15 PM, Bryan Dietz wrote:

In its most basic usage, it is used for faster access to file
objects(mostly).

simple setup given enough memory
create a subsystem with a fixed amount of memory, enough to "hold" the
file in question. this pool is typicially not used to run jobs.

then issue the command something like:
SETOBJACC OBJ(LIBRARY/FILE) OBJTYPE(*FILE)
POOL(*SHRPOOLXX) *or* POOL(*N XX)
*depends on how you set the subsystem...

more reading:
http://www-912.ibm.com/s_dir/slkbase.nsf/$$Search?openform
search term "setobjacc"

--bryan


rob@xxxxxxxxx said the following on Fri, 2/15/2013 4:02 PM:

So, that all being true, then what is the purpose of SETOBJACC?


Rob Berendt