Re: Keeping OS/400 objects permanently on main memory

Many thanks to everyone for their help.

Having read all the answers carefully, it seems that making the change is
not a priority as the only applications that run on the system are all ERROS
based and all use the same code and PFs. No LFs are used. So presumably
the main programs and the metadata PF will rarely be paged out.

The reason that I asked the question was that I had just upgraded main
memory and wondered whether SETOBJACC was a good idea but couldn't remember
the name of the command.

If performance becomes an issue or I have nothing to do (fine chance!), then
I will give it a try. At least now I know what to do - many thanks to you
all.

I am aware of the need to retain observability for later releases. I just
quoted without observability. With observability, the main programs are a
little over 14Mb - still very small.

Rob Dixon

On 9 September 2011 16:44, Mark S. Waterbury <mark.s.waterbury@xxxxxxxxxxxxx

wrote:

Hi, Rob:

In addition to what others have said regarding the use of SETOBJACC,
please consider the following:

1.

if you load a Physical File (PF) with SETOBJACC, you probably
should also load any Logical Files (LFs) that may exist over that
PF and that will likely be used by the application(s), so that the
LF indexes will also be pre-loaded into the same memory pool.

2.

to use SETOBJACC effectively, you must use a separate memory pool.
This means that whatever real main storage (memory) is assigned to
that pool can never be used by any other jobs for any other
purposes. With today's newer very fast POWER6 and POWER7 systems,
which have much larger main storage sizes than previously
available, it might be better to just let the system manage all of
the available main storage via the normal paging mechanisms.
Specifically, any pages referenced will be brought into main
storage on "first use" and should remain there, so long as there
is not enough other activity to cause them to get paged out
(selected for removal / replacement).

3. another option is to just ensure that all users or jobs running
ERROS always run in a specific ERROS subsystem, and that way,
those jobs can all share the same memory pool(s) assigned to that
subsystem. In this way, all ERROS programs, display files, and
PFs and LFs will use memory allocated from that subsystem's memory
pool(s), and thus, no other non-ERROS jobs on the system will
interfere with the ERROS jobs, at least, as far as "stealing"
memory pages is concerned. (Of course, other jobs can still
compete for CPU resources, but you can control this to some extent
by manipulating the "run priority" of jobs that run in the ERROS
subsystem, so they run at a slightly higher priority than "normal"
batch or interactive jobs. You can control this using the Job
Description (*JOBD) used for ERROS. This can be set up fairly
quickly, and does not require any programming changes and you do
not need to determine which *FILEs etc. should be "pre-loaded" as
you would have to do with SETOBJACC. This should achieve much the
same effect as using SETOBJACC. Note that if the memory pool(s)
assigned to the ERROS subsystem is large enough, you can still
issue SETOBJACC to load the most frequently accessed tables
(especially meta-data, etc.) into that pool ahead of time, to
further improve overall performance.

You also mentioned removing observability -- I think this may be a "bad
idea" because this could prevent your customers from migrating to i5/OS
V6R1 or i 7.1 in the future.

Hope that helps,

Mark S. Waterbury

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.