Re: New to RPG

I think I can contribute something to a thread about what to teach a new
RPGer.


On 4/27/2017 2:38 PM, James H. H. Lampert wrote:

I truly fail to understand the abject terror some people seem to have
about The Cycle. I can understand abject terror about doing mass updates
via SQL, but not about The Cycle.

No abject terror from me; I actively maintain the last matching record
programs in my group. I love the elegance of the RPG cycle, and I
absolutely do use it where it fits. It is wonderful for batch work; I
have thousands of cycle programs in production for exactly that purpose.

However.

That space gets smaller every year as more and more work moves away from
batch-at-a-time and into transaction-at-a-time.

With regard to using SQL to do some mass-update to a file, the VERY IDEA
gives me nightmares. Using the SQL approach for that can SCREW UP A LOT
OF RECORDS VERY FAST, WITH NO WAY TO HALT THE CARNAGE AT ONE DAMAGED
RECORD. Using explicit reads in an explicit do-loop instead of what's
already built into the language is sometimes necessary, to be sure, but
often it just amounts to re-inventing the wheel.

Whether I process an entire file with Update Primary, SQL, or a
hand-rolled READ loop, I'm still processing all the records. If I have
a logic error, I'm going to break all those records no matter what my
delivery method is. The important thing for OP to note is that many,
many RPG programmers use SQL, either embedded into our RPG, or
standalone, and SQL is no more dangerous than Update Primary is.

Likewise, modern interactive programs tend to run inside an event-loop
of some kind; The Cycle provides a perfectly serviceable built-in
event-loop.

The RPG cycle responds to exactly one event: Read Another Record. I
guess it's an event loop. Technically. ish.

Level breaks? Secondary files? I can't recall ever using either one, and
I certainly couldn't tell you how to do so (if I ever DID have a clue
how they work).

I can't remember the last time I used the RPG cycle without level
breaks. I wrote one of those last week to generate a paper report.


For OP, the key to understanding this debate is to understand that for
most of us, the cycle is intimately and forever bound to a multitude of
indicators, spaghetti code littered with GOTOs, terse variable names in
ALL CAPS, and eleventy-nine business tasks stuffed into a thousand line
program because someone thought that it would be easier to cram jam one
more thing into an existing program than it would be to write a new one.
Bad juju.

I don't think that James is talking about writing that stuff now, today.
Today, I don't need to program describe a file to assign level
indicators, and I haven't written a GOTO in a decade or more. The
indicators I use in any given cycle program can be counted on one hand.
It's good code, modern code, and anyone in my group can maintain it.

But I totally agree with the consensus that the time to write new cycle
programs is mostly past us. The very first thing I would teach a
newcomer to RPG is how to bind to an existing service program, hands
down. Learn to re-use without re-copying!!! The second thing would be
to write local sub-procedures. Especially if our theoretical newcomer
will be maintaining older cycle code. Sub-procedures saved my sanity in
a massive, nasty old cycle beast specifically because I was able to
isolate my new functionality away from the global-scope nightmare that
is the mainline of this thing. **free is a given for new code, and
/free calcs for mods to existing code.