Re: Setll vs. chain

[Jim Langston <jlangston@xxxxxxxxxxxxxxxx>]

Carl,

Would it be possible for you to build a logical over the file that
contains the formulas to look up?  Build it with the formulas being the
key filed (non unique of course).  Then you can just whizz though the
ones that you know have a formula.

Regards,

Jim Langston

"Sims, Ken" wrote:

> 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
> +---

+---
| 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
+---