RE: SETOBJACC and file performance

Tony, it should certainly speed things up assuming it is used properly.

SETOBJACC "preloads" the object into physical memory.  If used to place the
object in an unused memory pool, the object will remain in that pool an
never be swapped out to disk.  Once the object is completely loaded into
memory, no physical disk I/O need be performed.

This would be particularly beneficial with RANDOM I/O to the object.  With
sequential I/O, I believe you could use blocking to achieve about the same
benefits.

Double check that the object is being placed into an unused pool however.
If not, the it is likely that the object ends up being swapped out and you
lose the benefits of SETOBJACC.


Charles Wilt
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
 

> -----Original Message-----
> From: Tony Carolla [mailto:carolla@xxxxxxxxx]
> Sent: Wednesday, December 08, 2004 3:26 PM
> To: RPG programming on the AS400 / iSeries
> Subject: SETOBJACC and file performance
> 
> 
> I am working with an application that maintains a copy of data from
> several libraries, and uses a brute-force 'read all records and
> compare' strategy.  Inside the CL that calls the RPG, the files that
> are to be read from are specified in several SETOBJACC commands.  The
> help for this command leads me to believe that this is set up to
> accelerate the performance of database READs/WRITEs/UPDATEs.
> 
> Does anybody have any experience with this method?  Does it simply
> allow larger record block sizes?  What are the pitfalls, and finally,
> if I am updating files that have dependent logicals, is this safe?
> 
> 
> -- 
> "Enter any 11-digit prime number to continue..."
> --
> This is the RPG programming on the AS400 / iSeries (RPG400-L) 
> mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>