Brewing Through the RPG Cycle: From Implicit Logic to Explicit Control
☕ Today’s Coffee: Starbucks Pumpkin Spice Latte — warm, seasonal, and a reminder that some classics never truly disappear, even if they evolve.
Introduction
Back in the earliest days of RPG, programming looked very different from
what we know today. Before free-form RPG, before modular service programs,
before SQL integration—there was cycle programming.
Cycle programming was RPG’s original “magic trick.” Developers could
write very little code, and the RPG cycle itself would handle looping through
records, handling indicators, and even printing reports. At the time, this was
revolutionary: less typing, fewer bugs, faster results.
But over time, what was once considered efficient began to feel like a
straitjacket. Today, cycle programming is rarely taught, barely discussed, and
almost always refactored out of production code. Still, for those maintaining
legacy systems—or those curious about the history of our craft—it’s worth
understanding how the cycle worked and what lessons it offers modern RPG
developers.
The RPG Cycle Explained
At its core, the RPG cycle was an implicit loop. Developers didn’t
need to write their own DO or FOR loops—the cycle automatically:
- Read the next record from a file
(often the “primary” file).
- Process calculations based on
indicator conditions.
- Optionally handle totals and
output logic at control breaks.
- Print report lines when
conditions were met.
- Repeat until end of file.
That meant an RPG program could be just a handful of lines long, yet
produce a full customer invoice report or sales summary.
Example: Old Cycle Logic
Here’s a simplified RPG III cycle snippet:
FSALES IP
E K DISK
FREPORT O
F 132 PRINTER
☕ Today’s Coffee: Starbucks Pumpkin Spice Latte — warm, seasonal, and a reminder that some classics never truly disappear, even if they evolve.
Introduction
Back in the earliest days of RPG, programming looked very different from
what we know today. Before free-form RPG, before modular service programs,
before SQL integration—there was cycle programming.
Cycle programming was RPG’s original “magic trick.” Developers could
write very little code, and the RPG cycle itself would handle looping through
records, handling indicators, and even printing reports. At the time, this was
revolutionary: less typing, fewer bugs, faster results.
But over time, what was once considered efficient began to feel like a
straitjacket. Today, cycle programming is rarely taught, barely discussed, and
almost always refactored out of production code. Still, for those maintaining
legacy systems—or those curious about the history of our craft—it’s worth
understanding how the cycle worked and what lessons it offers modern RPG
developers.
The RPG Cycle Explained
At its core, the RPG cycle was an implicit loop. Developers didn’t
need to write their own DO or FOR loops—the cycle automatically:
- Read the next record from a file
(often the “primary” file).
- Process calculations based on
indicator conditions.
- Optionally handle totals and
output logic at control breaks.
- Print report lines when
conditions were met.
- Repeat until end of file.
That meant an RPG program could be just a handful of lines long, yet
produce a full customer invoice report or sales summary.
Example: Old Cycle Logic
Here’s a simplified RPG III cycle snippet:
FSALES IP
E K DISK
FREPORT O
F 132 PRINTER
C Z-ADD1 COUNT
C
SALE$ ADD TOTAL
GTOTAL
C EXCPTPRINT
C
*INLR SETON
Looks small, right? But what’s happening is much larger:
- RPG is automatically reading
through the SALES file.
- Each record increments COUNT.
- Totals are accumulated
automatically.
- The EXCPTPRINT line says: “print using the
REPORT format” — no loop required.
Why It Worked Then
Cycle programming was designed for business reports. In the 70s
and 80s, companies needed endless daily, weekly, and monthly reports: invoices,
balance sheets, payroll summaries. Writing a dozen lines that produced a
professional report was a huge win.
- Efficiency: Developers didn’t reinvent the
loop.
- Consistency: Reports looked uniform across
the system.
- Speed: Less code meant less to debug.
At the time, RPG’s cycle programming was a selling point—it let
businesses “program less and do more.”
Why It Doesn’t Work Now
Fast forward to today, and cycle programming feels more like a trap than
a shortcut.
- Implicit Logic – Business rules are hidden in
the cycle. Developers reading the code often ask: Where’s the loop?
Where’s the logic? It’s invisible unless you know the cycle rules by
heart.
- Limited Flexibility – The cycle assumed linear file
reads and printed reports. Modern applications are interactive, modular,
and service-oriented. The cycle can’t keep up.
- Steep Learning Curve – New RPG developers trained on
free-form find cycle code cryptic. It’s hard to onboard when logic isn’t
explicit.
- Maintainability Issues – Debugging cycle code is
tricky. “Magic” only works until something breaks.
A Modern Equivalent
Compare that earlier RPG III snippet to a free-form RPGLE program:
ctl-opt dftactgrp(*no) actgrp(*new);
dcl-f Sales usage(*input) keyed;
dcl-f Report printer(132);
dcl-s Count int(10) inz(0);
dcl-s GTotal packed(15:2) inz(0);
for;
read Sales;
dow not %eof(Sales);
Count += 1;
GTotal += Sale$;
except Print;
read Sales;
enddo;
endfor;
*inlr = *on;
This code is longer, yes—but it’s explicit. Every developer can
see the loop, the read, the accumulation, and the print logic. Nothing is
hidden in an implicit cycle.
Why It Matters Today
Many IBM i shops still have cycle code running in production. It works.
But when those programs need changes, modern developers are left scratching
their heads. Refactoring cycle programs into free-form is not just
modernization—it’s survival.
Understanding cycle programming helps in three ways:
- Maintenance: You’ll know what that “magic”
is doing before you replace it.
- Refactoring: You can break it apart
confidently without losing functionality.
- Perspective: You’ll appreciate just how far
RPG has come.
How to Read Cycle Code Today
If you find yourself staring at cycle RPG, here’s how to make sense of
it:
- Identify the primary file
(first file declared). That drives the loop.
- Look for indicators (*IN01, *INLR, etc.). These control printing,
totals, and conditions.
- Map totals to the break levels—that’s
where cycle automatically prints summaries.
- Rewrite as an explicit loop
in free-form, one step at a time.
Final Sips
RPG’s cycle programming is like the Pumpkin Spice Latte—a little
old-fashioned, but iconic. It may not be practical for today’s enterprise
systems, but it shaped the culture of IBM i development.
By understanding where RPG came from, we gain perspective on where it’s
headed. And as we blend modern free-form RPG with tools like GitHub Copilot,
we’re not so far from that same vision: faster development, less boilerplate,
and more focus on business value.
C Z-ADD1 COUNT
C
SALE$ ADD TOTAL
GTOTAL
C EXCPTPRINT
C
*INLR SETON
Looks small, right? But what’s happening is much larger:
- RPG is automatically reading
through the SALES file.
- Each record increments COUNT.
- Totals are accumulated
automatically.
- The EXCPTPRINT line says: “print using the
REPORT format” — no loop required.
Why It Worked Then
Cycle programming was designed for business reports. In the 70s
and 80s, companies needed endless daily, weekly, and monthly reports: invoices,
balance sheets, payroll summaries. Writing a dozen lines that produced a
professional report was a huge win.
- Efficiency: Developers didn’t reinvent the
loop.
- Consistency: Reports looked uniform across
the system.
- Speed: Less code meant less to debug.
At the time, RPG’s cycle programming was a selling point—it let
businesses “program less and do more.”
Why It Doesn’t Work Now
Fast forward to today, and cycle programming feels more like a trap than
a shortcut.
- Implicit Logic – Business rules are hidden in
the cycle. Developers reading the code often ask: Where’s the loop?
Where’s the logic? It’s invisible unless you know the cycle rules by
heart.
- Limited Flexibility – The cycle assumed linear file
reads and printed reports. Modern applications are interactive, modular,
and service-oriented. The cycle can’t keep up.
- Steep Learning Curve – New RPG developers trained on
free-form find cycle code cryptic. It’s hard to onboard when logic isn’t
explicit.
- Maintainability Issues – Debugging cycle code is
tricky. “Magic” only works until something breaks.
A Modern Equivalent
Compare that earlier RPG III snippet to a free-form RPGLE program:
ctl-opt dftactgrp(*no) actgrp(*new);
dcl-f Sales usage(*input) keyed;
dcl-f Report printer(132);
dcl-s Count int(10) inz(0);
dcl-s GTotal packed(15:2) inz(0);
for;
read Sales;
dow not %eof(Sales);
Count += 1;
GTotal += Sale$;
except Print;
read Sales;
enddo;
endfor;
*inlr = *on;
This code is longer, yes—but it’s explicit. Every developer can
see the loop, the read, the accumulation, and the print logic. Nothing is
hidden in an implicit cycle.
Why It Matters Today
Many IBM i shops still have cycle code running in production. It works.
But when those programs need changes, modern developers are left scratching
their heads. Refactoring cycle programs into free-form is not just
modernization—it’s survival.
Understanding cycle programming helps in three ways:
- Maintenance: You’ll know what that “magic”
is doing before you replace it.
- Refactoring: You can break it apart
confidently without losing functionality.
- Perspective: You’ll appreciate just how far
RPG has come.
How to Read Cycle Code Today
If you find yourself staring at cycle RPG, here’s how to make sense of
it:
- Identify the primary file
(first file declared). That drives the loop.
- Look for indicators (*IN01, *INLR, etc.). These control printing,
totals, and conditions.
- Map totals to the break levels—that’s
where cycle automatically prints summaries.
- Rewrite as an explicit loop
in free-form, one step at a time.
Final Sips
RPG’s cycle programming is like the Pumpkin Spice Latte—a little
old-fashioned, but iconic. It may not be practical for today’s enterprise
systems, but it shaped the culture of IBM i development.
By understanding where RPG came from, we gain perspective on where it’s
headed. And as we blend modern free-form RPG with tools like GitHub Copilot,
we’re not so far from that same vision: faster development, less boilerplate,
and more focus on business value.
Comments
Post a Comment