× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



We do it here to help our batch times & there is a significant performance
improvement.

However, it's all or nothing.  You can also load logical files {if smaller}.


We added more ram to accommodate our 6 files.

\Vincent

 -----Original Message-----
From:   Tony Carolla [mailto:carolla@xxxxxxxxx] 
Sent:   December 8, 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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.