MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » February 2013

Re: SETOBJACC Was: SSD Best practices



fixed

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







Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact