Re: CHAIN Versus SETLL and READ When Data Needed -- RPG400-L

Sure, but the difference between CHAIN and SETLL will not make the code any
more or less maintainable.  That being the case, and especially since there
was initially discussion about making a corporate standard out of this, then
it makes sense to identify the best performing route.

'Most efficient' is a nasty thing to gauge, and some of the worst code Ihave ever been exposed to was a result of preemptive optimisation.There's just no simple answer to knowing whether SETLL or CHAIN willperform better unless there is a deep understanding of the underlyingdata population. Perhaps the most significant performance enhancementis to narrow the width of the returned record [1]

For Shannon's particular case, he ought to model it both ways and run asimulation to see which one performs better. This is pretty much mystandard performance tuning advice these days. Oh, and keep the testbed handy because when you add memory or change disk drives or add a PTFor change the composition of the database, performance will change.

As far as a standard goes, I think that I'd settle (no pun intended) ona standard that makes the code easier to work on. An example might beto use SETLL when the intent is to retrieve a group of records like allthe items bought by a particular customer. And to use CHAIN to retrievea single record such as the customer master record. Then, anyone seeingSETLL knows that the intent is to fill a subfile or some similar 'set'chore.


  --buck

[1] Let's say the record we're looking at has 300 fields and is 4000bytes wide. If we have to read/chain to that file a thousand times,we've told OS400 to shuffle 4 million bytes and made RPG populate 3hundred thousand fields. If we only need the name, or an active flag orsomething much smaller AND we've determined that performance needsimprovement, create a logical file with the same key structure. It'llshare the access path, causing virtually no extra overhead in thatregard. Include only the fields we need to see, say it's a name of 30characters. Now instead of 4 million bytes, OS400 only needs to movethirty thousand. Quite an improvement and the only program changeneeded is either changing the F-specification or issuing an OVRDBF.This is just an example with round numbers; what real iSeries programwill have a performance problem with a thousand records?

Reducing the I/O can happen either by issuing fewer I/O operations or byrequesting less daa to be moved into the RPG buffers.