Re: Difference between RPG III and RPG IV with CHAIN

Vern Hamberg wrote:

I separate SETLL/CHAIN from the various READ* because you use a different BIF to test results. %found() (or %equal()) vs %eof(). So if

Understood, but I wouldn't use %FOUND() for such a SETLL. For the specified circumstance of processing duplicate keys, I'd think that %EQUAL would be wanted. Unfortunately, %FOUND for SETLL doesn't mean the same as %FOUND for CHAIN. It means a 'lower limit' was found for SETLL, but a matching record was found for a CHAIN, no?

Nevermind... I re-read what you wrote and now interpret it better (I think.)

Anyway...

SETLL
if %EQUAL
READE
dou %EOF
...process
READE
enddo
endif

With CHAIN, it'd be:

CHAIN
if %FOUND
dou %EOF
...process
READE
enddo
endif

Not particularly different in complexity. (Hope I remembered my %bifs correctly there.) I was just curious why it'd be undesirable. It works well enough; and with the code so compact in both cases, it's hard to see why anyone would be confused...

...unless there was no understanding by some maintenance programmer that CHAIN might do both parts of SETLL and READE in a single operation. To consider that to be a problem seems to me like saying EXFMT would be confusing because it does both WRITE and READ in a single operation. Why is one acceptable and not the other?

BTW, does SETLL with %EQUAL prevent a deletion before the READE? I see that there's a _very slim_ possibility that the two techniques could give different results.

Tom Liotta

lgoodbar wrote:

It "reads" wrong to me. To me CHAIN implies an intent to retrieve one
row and only one row, while SETxx/READE implies an intent of reading a
group of rows (1+). I also do not like mixing CHAIN as the prime and
READx as the looping construct. It looks like a mixed metaphor.

It's more personal preference than anything, likely due to starting with
RPG/IV (mid-1990s).

-----Original Message-----
Loyd Goodbar wrote:

IMO, chain is the wrong tool for looking at files with duplicate keys.

I've

only used chain when key values are unique, or SETxx and READxx for
duplicate-keyed files. Know your data...

Why? Especially for duplicate keys, CHAIN plus READE can work great. The CHAIN not only does the SETLL but also a 'priming' READ for a loop. Just wondering why it should be avoided.