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.
On 2/15/2013 3:15 PM, Bryan Dietz wrote:
In its most basic usage, it is used for faster access to file
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...
search term "setobjacc"
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?