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


  • Subject: RE: Setll vs. chain
  • From: "Sims, Ken" <KSIMS@xxxxxxxxxxxxxxxx>
  • Date: Thu, 10 Feb 2000 12:21:58 -0500

Hi Carl -

>Date: Wed, 9 Feb 2000 20:06:47 -0330
>From: "Carl Pitcher" <cpitcher@roadrunner.nf.net>
>Subject: Setll vs. chain
>
>We have a report program that processes a master file of 300,000+ records
>which runs ever so slow.  Each record chains to a formula file to see if a
>formula exists and does some calcs. Out of the total master file, there
>would be no more than 1000 successful hits on the formula file.  Before I
go
>ripping this code apart (and converting it to RPGIV in the process), my
>expectation is that if I change the CHAIN to a SETLL and then chain on a
>successful hit that it should improve the performance considerably.  Am I
>wrong in assuming that SETLL will just look at the "index" which should be
>in memory as opposed to CHAIN which most often requires an access to disk
to
>retrieve the record? TIA.

Yes, SETLL just looks at the index, but if the CHAIN doesn't get a hit, it's
only going to look at the index as well.  The net result ... if you add the
SETLL and only CHAIN if there is a record there to find, I think it will
actually end up slower by the amount of the time taken by the SETLLs
preceding successful CHAINs.  SETLL in place of CHAIN is beneficial when you
don't care about the contents of a record but only its existence, so you
just totally replace the CHAIN with SETLL.  Since you need the formula from
the formula, this doesn't apply to your situation.

Fortunately there ARE ways to speed up your process.  If the formula file is
small enough, at the beginning of the program read it into an array or
multiple occurrence data structure.  Looking for the formulas in memory is
much faster than going to a file.  Similiar things can be done with a user
index or user space; but that might be getting into areas beyond your
current comfort level.  There are also faster ways many times to find things
in an array than just using LOOKUP; but simply loading an array at the
beginning and replacing CHAINs with LOOKUPs would certainly be the simplest
change to the program and would provide a substantial time savings.

If the formula file has a lot of records but the actual number of different
values in the master file is small, you can go a different route where you
build arrays on the fly, one of values in the master file that do not exist
in the formula file, another array of formula records that you have already
used in the program.

Another possibility, if your processing will allow it, read the master
through the logical by formula.  Only chain to the formula file at the
beginning of each group of master records that have the same fomula.

There are many possibilities.  If you can give us more information about the
formula file, how many records in the file and how many fields in the
records; and how many different formula values there are in the master file;
more specific suggestions can be made.

Ken
Southern Wine and Spirits of Nevada, Inc.
Opinions expressed are my own and do not necessarily represent the views of
my employer or anyone else.

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.