RPG Cycle and other implicit Logic

The RPG Logic Cycle: What It Was, Why It Existed, and Why You Still Need to Understand It

Right then, let's talk about something that powered IBM i business applications for decades but rarely gets mentioned in polite modern RPG conversation. The RPG Logic Cycle.

If you have ever opened an old RPG400 program and wondered why the code seems to jump around with no obvious Do loop or Read statement in sight, this is why. The logic cycle was the invisible engine that drove the whole thing.

What Was the RPG Logic Cycle?

RPG (Report Program Generator) was built in the 1960s as a language for producing business reports quickly. The logic cycle was a fixed, built-in sequence of steps that every program followed automatically.

You defined a primary input file in your F-specs. The system then took care of:

• Opening the file
• Reading every record in order
• Detecting when control fields changed (think customer number or invoice date)
• Running the right calculations at the right time
• Writing heading, detail, and total lines
• Closing everything down cleanly at the end

You did not write the main loop. The compiler and runtime did it for you. That was the whole point.

Why Was It Used?

Back in the day most RPG work was batch reporting. Files were processed sequentially. The typical pattern was always the same:

Read a record → Do some detail work and print a line → If a control field changed, print subtotals for the previous group → At end of file print grand totals.

The logic cycle automated all of that. It gave you control level indicators (L1 through L9) that turned on automatically when a control field changed. It gave you the LR (Last Record) indicator to know you had reached end of file. It gave you the 1P (First Page) indicator for headings that only print once.

You could write an entire report program with very little explicit logic. Just define your input fields, your control fields, your calculations conditioned on L1/L2/etc or no indicator at all (detail time), and your output lines marked H, D or T. The cycle did the rest.

It was simple, consistent, and extremely efficient for the report-writing workloads of the 1970s, 1980s and early 1990s. Perfect for the punched-card and early database era on System/38 and AS/400.

How Did the Cycle Actually Work?

Here is the basic flow (slightly simplified but accurate enough for real-world understanding):

1. First time through only  Do initial housekeeping, resolve parameters, set 1P indicator on, write any heading or detail lines conditioned on 1P.
2. Process heading and detail output Write H and D lines that are conditioned on the current indicators.
3. Read the next primary record The system reads it for you and sets the appropriate record identifying indicators and any control level indicators (L1-L9) if a control field has changed since the last record.
4. Total time processing If a control break or LR just turned on, run any calculations conditioned on L1-L9 or LR. Then write any T (total) output lines.
5. Check for end If LR is on, do final cleanup and end the program.
6. Move input data Copy the just-read record fields into the program fields and set any field indicators.
7. Detail time processing Run calculations that have no control level indicator in columns 7-8. These happen for every single record.
8. Go back to step 2 and repeat until LR is set.

The key thing to remember is the timing. Total calculations and total output happen before the detail processing of the record that caused the break. That little detail has caught out many a maintenance programmer over the years.

Why We Stopped Using It

By the mid-1990s business requirements had moved well beyond simple batch reports. We needed interactive programs, complex transaction logic, display files, web services, and proper modular code.

The fixed cycle became a straitjacket. You could not easily:

• Read files in any order you wanted
• Call the same program recursively
• Structure code into clear procedures
• Handle errors and exceptions the way modern languages expect

So IBM gave us RPG IV with free-format syntax (around 2001) and the ability to write linear-main procedures instead of cycle-main ones. In a linear-main program you control everything yourself with explicit Open, Read, DoU *INLR, Close and so on. It looks and behaves like code in other languages. It is easier to read, easier to test, easier to maintain, and far more flexible.

Today we almost always write new code without the cycle. We use /FREE or all-free RPGLE and we decide the flow ourselves.

Why You Still Need to Understand the Logic Cycle

Here is the bit that matters in 2026.

There are still thousands of production RPG programs running on IBM i systems that were written with the logic cycle. Some are twenty, thirty, even forty years old. They process your orders, your payroll, your inventory, your financials. They just keep working.

When you are asked to:

• Fix a bug in one of these programs
• Add a new field or calculation
• Extract some business logic so it can be reused
• Refactor it into modern free-format RPGLE

…you need to know how the cycle works. Otherwise you will not understand:

• Why a calculation only happens on the first record of a group
• Why totals appear in the wrong place after your change
• What LR and the L indicators are actually doing
• How the original programmer intended the control breaks to behave

Modernising legacy code is much safer and faster when you can read the old cycle-based program and correctly replicate its behaviour in a new procedural version. The cycle is not just history. It is part of the living code base that still runs the business.

Bottom Line

You will probably never write a new program that relies on the RPG logic cycle. That ship sailed a long time ago.

But if you work on IBM i systems you will almost certainly have to read, fix or modernise code that does. Understanding the cycle makes you a better guardian of that legacy and a more effective moderniser when the time comes to drag those old programs into the current decade.

The cycle was a clever solution to the problems of its time. We have better tools now, but the old programs are not going away any time soon. Knowing how they worked is still part of the job.

That is the theory sorted. Next time we will look at a small real-world example of an old cycle program and walk through how we would rewrite it in clean modern free-format style without losing any of the original business rules.

Until then, keep your indicators meaningful and your control breaks sensible.