With SETOBJACC there is another concern. If you write to that object, meaning update it at all, it will be forced out of memory to DASD at some point by storage management to maintain integrity losing any advantage to having them in memory in the first place. So those objects by definition need to be read only. It's really tough to find objects that will A) fit into memory, and B) are truly read only.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark S Waterbury
Sent: Friday, December 15, 2017 10:46 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Subsystem and memory pools
Paul,
IBM i, like OS/400 and CPF before it, are "pure paging" systems.
With single level storage, everything resides in virtual storage, so main storage is just a "cache" for the parts of objects that are actively "in use" at the moment.
With today's POWER systems, we have real main storage (memory) sizes that are vastly larger than just a decade ago ... one or two orders of magnitude larger. Also, you may be using SSD, which is much faster than spinning disks for the actual "backing store" (where objects permanently reside in single-level storage).
So, I think it might actually be better to try the QBASE approach of having everything just run in the *BASE memory pool, and let the system "paging" mechanisms take care of keeping the frequently used pages in real memory, regardless of whether they are pages for batch jobs, interactive jobs, server jobs, whatever.
Also, based on the above, I would advise against heavy use of SETOBJACC or KEEPINMEM, except perhaps for a few very special cases, because this forces the OS to "bring" (or "page in") the entire object, whether or not you actually need all of it, thus using up valuable "page frames"
in real memory, that could cause other objects (programs or data) that is needed by other jobs to get "paged out" to make room for those objects you are forcing the system to "bring" into real memory.
I hope this helps,
Mark S. Waterbury
On 12/15/2017 11:24 AM, Steinmetz, Paul wrote:
Rob,
1) How much do you use?
Keep in memory (KEEPINMEM)
Specifies whether the data for a file member should be brought into
a main storage pool by the SQL Query Engine (SQE) when the data is
used in the query to improve the performance.
2) Do you use Set Object Access (SETOBJACC)?
The Set Object Access (SETOBJACC) command temporarily changes the
speed of access to an object by bringing the object into a main
storage pool or purging it from all main storage pools. An object can
be kept main storage resident by selecting a pool for the object that
has available space and does not have jobs associated with it.
Repeated use of the command can cause a set of objects to be resident
in a main storage pool.
Paul
--
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:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD
midrange.com
