SETLL+READ vs CHAIN

[K.Forsythe]

I would not expect a chain to be significantly faster than a SETLL followed by a READE. Although if you know you are only retrieving one record, then obviously CHAIN makes more sense, and might be slightly faster. The performance difference should be so small that you would probably not detect it unless you performed the transactions thousands of times in a row. I suspect the performance difference is caused by something else, such as a rebuild of the access path, record lock, file open, etc... Try putting the CHAIN ahead of the SETLL and READE and see if the same performance discrepancy is found. And, just as a wild thought... You might consider performing a RGZPFM command to purge deleted records and see if that has any impact. Good luck.

[Guest.Visitor]

SETLL+READ vs CHAIN

You stumbled across a neat trick in RPG. You ever notice that compile message that says "RNF7086 RPG handles blocking for the file"? Of course, we all have, but we get so used to seeing it and we typically ignore it. Well, if a file has a SETxx or a READE/READPE in the program, the compiler disables record blocking. BUT, if you do a CHAIN followed by a READ (not a typo, a READ), you will see the RNF7086 in the compile listing and your program might fly because it's using record blocking on that file. But, you have to manually check for key breaks yourself, which is not a big deal when you gain some performance. Chris

[T.Grove]

SETLL+READ vs CHAIN

There's a gotcha to using the chain, however. A few years ago a fellow programmer and I discovered that IBM had "Fixed" a problem in the ILE compiler. A chain is not the equivelant of a setll/reade pair when using a partial key. I saw with my own eyes in debug where the chain did not select the first key value where the partial key was found. For example: Key fields in file FieldA Numeric Ascending FieldB Numeric Ascending FieldC Numeric Ascending When chaining on FieldA,FieldB one would assume that if records were in the file that had a value for FieldC of 1, 2, 3 that they would be read in that order. They are not necessarily read that way. We would consistantly get diferent records, sometimes 2 first, sometimes 3, sometimes 1. However, we always retrieved the records in their proper order when using a SETLL/READE pair using the partial key. We called IBM on this and spoke to the RPG group. That's when we were told that they had "Fixed" the compiler. (I don't understand what it was that they were fixing, but that was their reply)

[DaleB63]

SETLL+READ vs CHAIN

Performance isn't the only issue here. When we all lived in the land of indicators, you could use the same indicator for CHAIN's not found, and for READE's end of file. And you could use that indicator to control a DOx loop. But if you eliminate the indicators, you need to deal with %FOUND vs. %EOF. By using SETLL/READE, you only have %EOF, so loops are easier to deal with. And, of course, no indicators for any of these operations in free format.

[Guest.Visitor]

SETLL+READ vs CHAIN

I've been using this technique for a long time but not on partial keys. I was told by someone a long time ago (he was supposedly an IBM guru) that a chain will get the first record of a partial key in arrival sequence. So, if FieldA was 10, Filed B was 20 in 20 records and FieldC was 1 through 20. If the records were originally written in FieldC order, the first record should be correct beacuse the arrival sequence/RRN order is the same as the key order. But if the records were written where FieldC values were 15,6,8,20,1... not in order by the key field, the first record retrieved by the partial key would be where FieldC=15. If the full key is used in the chain, it reads by the key order. CHAIN was never intended to be used as a substitute for SETLL. At least that's what the guru said. I don't use CHAIN anymore as a SETLL. I'm using free-format and it's a pain to deal with %FOUND, %EOF. Regards, Tom.

[Guest.Visitor]

SETLL+READ vs CHAIN

TAGrove / Tom, So, do you know when IBM "unfixed" this? The CHAIN/READ combination works fine (reads by partial key, not RRN) in free form on V5R2. As Ronald Reagan always said, "trust but verify". Chris

---

Code

[mamadou_toure@yahoo.com]

SETLL+READ vs CHAIN

Hi, I performed a SETLL + READ to start processing a group of record, while debugging, I noticed that the SETLL command took a longtime to execute, but when I replace the SETLL by a CHAIN, it's too fast. Could we say that CHAINING is better and faster than performing a SETLL ? Thanks