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



Hi Tom

Had to think about that CHAIN example - I like that - will likely use it sometime. It makes the priming read method a little cleaner looking, as you said.

I'm not sure about preventing a deletion with SETLL and equal() - that'd require a record lock, and I don't think we have a record to lock yet.

Thanks
Vern

Tom Liotta wrote:
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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.