Re: SETOBJACC Was: SSD Best practices

[Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>]

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