RE: Keeping OS/400 objects permanently on main memory

Mark,

I didn't think that observability, per se, was what the 6.1 and 7.1
conversions needed. Probably speaking out of school here because my mind
can't recall exactly what it was that they needed.

Obviously, correct me if I am in error and, if not, remind me what it is
that the conversions do need.

Thanks.

Jerry C. Adams
IBM i Programmer/Analyst
Times are so tough my wife decided we should have a two-income family. Now
I'm working two jobs.
--
A&K Wholesale
Murfreesboro, TN
615-867-5070


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark S. Waterbury
Sent: Friday, September 09, 2011 10:45 AM
To: Midrange Systems Technical Discussion
Subject: Re: Keeping OS/400 objects permanently on main memory

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