The average RPG developer can quickly become proficient in replacing RPG database operation codes with their SQL equivalents when undertaking new programming. In each installment of this series, I will visit an op code or set of op codes in order to prove my contention. First up today is CHAIN.

I remember the CHAIN op code from System/3 Model 6 and Model 10 disk days. (Yes, I have been around for a long, long time.) It has been used extensively by every RPG programmer since then. It is the basic op code for random access. In the “old days” it

Today’s musings fall into the “why would anybody want to do that?” category. “Why would anybody want to be president?” asks Barack Obama. “Why would anybody steal a groundhog?” asks Rita in Groundhog Day. My question is, “Why would anybody pass 16,382 parameters to a subprocedure?” There is a better way.

I stand second to none in my admiration for parameters. The first system I learned to program, the IBM System/3 Model 12, allowed no parameter passing to RPG programs or OCL procedures. Cloning diminished–and life improved–when I started working on a S/34, which allowed OCL procedures to receive

The SQL implementation in DB2 for i is second to none. However, one irritating thing common to various SQL dialects is the need to repeat expressions in query. As SQL matured over the years, techniques such as nested table and common table expressions became available to, among other things, reduce repetitive expressions. This tip illustrates the use of the LATERAL correlation as another way to avoid repetition.

The Problem

Say you’re writing a report for a grocery wholesaler, where markup on food items is small and discounts are even smaller. Looking for orders that were not priced correctly, you’re tasked