RE: SETOBJACC and file performance

Tony,

I don't think so.  AFAIK, the whole idea behind SETOBJACC is to place the
entire object into memory.

I don't know what happens if you haven't got enough memory in the pool for
the entire object.  (Though you can specify just the objects *ACCPTH or
*DATA or *BOTH)

HTH,

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:51 PM
> To: RPG programming on the AS400 / iSeries
> Subject: Re: SETOBJACC and file performance
> 
> 
> 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?
> 
> 
> On Wed, 8 Dec 2004 15:44:22 -0500, CWilt@xxxxxxxxxxxx
> <CWilt@xxxxxxxxxxxx> wrote:
> > 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.
> > >
> > --
> > 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.
> > 
> > 
> 
> 
> -- 
> "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.
>