RE: SETOBJACC and file performance -- RPG400-L

rpg400-l-request@xxxxxxxxxxxx wrote:

>   4. Re: SETOBJACC and file performance (Tony Carolla)
>
>Hmmm... That sounds promising.  I wonder if the system makes a
>judgement as to how much of the object to load.  Example, I have a
>13.7Million record 1.4GB file, and I obviously wouldn't want to tie up
>1.4GB of memory, but would the system manage placing only reasonable
>portions thereof, based on the pool size?

Tony:

"...would the system manage placing only reasonable portions thereof"

Sounds very close to a piece of an IBM performance manual or redbook that I 
read that was discussing 'expert cache' back around V3R6/V3R7. Since I'm not 
totally clear on what your meaning is and I'm not the expert anyway, that might 
have little to do with your question. But, my understanding of SETOBJACC is 
something like this (high-level, simplified):

You tell the system what pool to load the object into. If the pool isn't big 
enough, only as many pages as will fit are brought in. The system 'manages' the 
'reasonable portion' from then on just as it manages portions of objects 
anywhere else in memory -- if pages are needed that aren't already in memory no 
matter what pool they might be in, they're brought in as needed. (I have no 
idea what pool they might be brought in to if parts are scattered; I suspect 
job pool gets first crack at it.) Such pages replace pages that haven't been 
used recently. If other objects are also in this pool, pages from those objects 
might replace pages of this object.

Ideally, this would be used with a private pool. The pool would be assigned to 
a subsystem and cleared via CLRPOOL to make sure everything in it is flushed 
out. Once cleared, SETOBJACC brings the requested object into the pool. As long 
as the pool is private and the object fits in the pool, access will be from 
memory from then on. If multiple objects are in the pool and they all fit, then 
they all stay in for the duration, i.e., until SETOBJACC POOL(*PURGE). Objects 
can be *PGMs or *FILEs.

If pools are already set up and used reasonably, I'm not sure that SETOBJACC 
for a 1.4GB file is likely to buy you much. If large sequences of physical 
records aren't accessed much, then those pages will just be taking up space 
with no usage. If all blocks of the file are relatively equal in access and 
access to the blocks happens numerous times, then _maybe_ there will be 
improvement; but I'd guess that you better have a lot of spare memory first.

Now, if this is a 500-record, 200K file that's used all over the system, 
programs accessing it over and over again all day long, then carving out 
dedicated space for it could make a decent difference. At least it wouldn't be 
in contention for space in a shared pool.

I haven't used SETOBJACC since OS/400 V3R2 where I had a major set of issues to 
overcome for a particular group of applications in a structured day/night 
environment. It was pretty useful then. But nowadays -- OS/400 V5, large memory 
spaces, etc. -- I'm way behind in practical knowledge.

Hopefully, there will be useful corrections or enhancements to the thread. I 
wouldn't mind updating what I understand.

Tom Liotta

-- 
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertech.com


__________________________________________________________________
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp