RE: CHAIN Versus SETLL and READ When Data Needed

There are a lot of programs that use this logic now (SETLL on a complex
key, and then working your way back to a less complex key until you get
a hit, followed by a read when you know the record is there so that you
can use the data from the record).

I don't disagree with you Scott. I'm just trying to understand what the
best way to go forward on this is since this has become an issue at the
office. 

I guess when it comes right down to it, I don't even really care that
much one way or the other except that if I had to choose, I'd choose
chain over setll for this type of problem just because that's how I've
always done it. 

I'll have to think about how I'd do this for multiple files, with
multiple keys (all having different key fields) in a procedure. I'm not
sure I could even do that, but I'll give that some thought.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Thursday, March 01, 2007 12:23 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: CHAIN Versus SETLL and READ When Data Needed

I posed this question on MCPressOnline the other day but I would like

to

get more opinions on it so I'll post it here too.   A shop-standard
hangs in the balance.

To me, this statement about a "shop standard" is a very strange one. 
How often do you need to write code like this?!  Seriously... does this 
come up a lot?  If you only have to write it once, then why would it be 
a shop standard?

Write a subprocedure, in a service program, that retrieves the closest 
match record.  Call that subprocedure from everywhere.  Make your shop 
standard to call that routine rather than to re-code something many 
times that should only be coded once!

Surely for maintainability's sake, it's easier to maintain the code in 
one place than in many?!

As for the difference in maintainability of SETLL vs CHAIN, or of 
performance between SETLL and CHAIN... who cares?  If you only have it 
coded once and the routine you've coded it in is short and simple, then 
nobody is going to have a hard time maintaining it!   And if you try it,

and the performance isn't acceptable, then you can change it and test it

in one place and solve the problem.  You could even change it to 
something more complicated (like the array that Rory suggested) if you 
need to, and there'd be only one place to change it.

Or do you have a lot of files that work the same way?