× 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.



If I understand it correctly you can use SETOBJACC to ensure the data is
available in memory rather than disk. I guess this might narrow the gap
between %lookup and chain even further.

At the very least it will muddy the waters regarding whether disk IO is
required ;)

Regards
Evan Harris


Hi, Carl:

In a single-level-storage environment such as the iSeries, the following
statement falls apart:

    "the CHAIN will require disk I/O"

If the record hasn't been purged from memory, it's going to beat LOOKUP,
hands down.

----

I worked in an environment where implementation the concept of a RAM disk
(remember those) on a S/38 was a requirement.  There was a master file with
a small number of records; ultra-fast access to these records was required,
so the design required "pinning" the records into memory.  Here's what we
did:

Create a subsystem with its own memory pool, large enough to hold those
records and an application to read them.  The application would cycle every
n minutes, just to be sure the latest changes to those records was in its
store.  Mostly, the application was in DLYJOB mode.  This application was
attached as an autostart entry on the subsystem description, and the
subsystem was added to system startup.  The effect was that, as the system
came to life, that memory pool was populated with the required data.  It
was always in memory (since the SBS had its own pool, it wasn't subject to
purge).  Voila!  RAM disk on a S/38.

Maybe some approach like this would satisfy your need?  I'd definitely
stick with the CHAIN, particularly if there's ANY chance that the data
might change after the application is initialized.

HTH





"Carl Galgano" <cgalgano2@ediconsulting.com>@midrange.com on 11/22/2002
09:22:30 AM

Please respond to midrange-l@midrange.com

Sent by:    midrange-l-admin@midrange.com


To:    <midrange-l@midrange.com>
cc:
Subject:    RE: %lookup vs. chain


Mike:
The array lookup is going to be much faster, as the array will be stored
in memory, the CHAIN will require disk I/O.  However, why not just
change a variable in your program (not store the flag in an array)?  I
think that would be the fastest and most efficient of all!
cjg

Carl J. Galgano
EDI Consulting Services, Inc.
550 Kennesaw Avenue, Suite 800
Marietta, GA  30060
(770) 422-2995 - voice
(419) 730-8212 - fax
mailto:cgalgano@ediconsulting.com
http://www.ediconsulting.com
AS400 EDI, Networking, E-Commerce and Communications Consulting and
Implementation
http://www.icecreamovernight.com
Premium Ice Cream Brands shipped Overnight

"You ain't gonna learn what you don't want to know" - rw

I'm just noticing that as I spin through some large files that I'm
chaining out a million times (actually more) to a control file to check
a flag.  In the initial subroutine I'm setting up an array that I could
easily store this flag in.  I'm wondering what the opinion is as far as
performance-wise which is more efficient, doing the %lookup() on the
array or chain to the file?


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.