Re: Record blocking optimization

[Alan C <steelville@xxxxxxxxxxx>]

Hi Rob,

> It will only work this way if you are doing matching records processing. 
> Otherwise it will work like this
>
> Dow Not %EOF(primary)
>     Read primary;
>     // Calc specs
> EndDo;
> Dow Not %EOF(secondary)
>     Read secondary;
>     // Calc specs
> EndDo;
>  
Yep, you got it!

> And, honestly, I am not sure if it does the calc specs (the first time) before, or after, the read.  I remember doing something like putting a record identification indicator and conditioning the calc specs on that indicator.  I have an old RPG coding template that might show me this.
>  
The calcs are done after the read, but there's a pre-read too! I really 
wouldn't recommend getting into it for somebody new to the language. 
When I was teaching RPG/400 when the AS/400 was new, I usually talked 
about RPG-II a little bit, because most of them would be working with 
RPG2 programs in converted S36 shops. Not anymore. The cycle was still 
often used, and OPNQRYF took care of primary file preparation, etc, so I 
talked about it. If I taught it again, I might very briefly cover that 
in case they come across one, but not much.

I think there would be a flowchart in the RPG-LE reference manual that 
lays it out exactly, because the compiler still generates code like 
that, but for most people they need that explained too! It can get 
complicated pretty fast, it's impressive how much coding the compiler 
generates for you when using the cycle.

For the most part instead of using the cycle, I generally use SETLL and 
READE and using externally described data structures generally meets the 
needs that may have made the RPG cycle useful otherwise, because I can 
prefix them as a sort of "pre-read", and move the data structure to 
another based on the same PF to do "detail time" processing.

D PreviewRecd  E DS  extname( FileX ) prefix( in )
D ItemRecd        E DS  extname( FileX )

> And Alan, it's not just COBOL programmers.  I sent some code to Jon Paris and 
> it stumped him for quite awhile too, until he realized that it had a  primary 
> file.  It's just not something that's assumed anymore.
>
> Rob Berendt
>  
That's caught me a couple times recently too.

Alan