7 Benefits of Converting Fixed-Format RPG to Free-Format

In the first article in this series, we explained why modernizing RPG applications can be a smarter choice than replacing an IBM i platform that continues to serve the business well. 

Now we will look more closely at the technical case for converting fixed-format RPG to free-format: what changes in the source, how that affects everyday development work, and which improvements require more than syntax conversion. 

A conversion tool can remove column dependencies while preserving existing program behavior. It does not automatically turn subroutines into procedures, eliminate every indicator, separate business logic from database access, or create a testable architecture. Those are refactoring decisions, with their own scope and validation requirements. 

The strongest modernization plans account for both stages instead of treating them as the same task. 

What Changes in a Free-Format RPG Conversion? 

Fixed-format RPG inherited a source layout in which the meaning of an entry depends partly on its position. Operation codes, factors, result fields, and indicators occupy defined areas of a calculation specification. Before a developer can follow the business logic, they must understand that layout. 

Fully free-form RPG removes those column rules. Statements can be indented according to their logical structure, names have room to be descriptive, and the source reads in the same direction that the program executes. 

Consider a simple fixed-format calculation: 

C                   IF        Balance > CreditLimit 
C                   EXSR      ApplyHold 
C                   ENDIF 
 

The same calculation in free-format RPG is: 

if Balance > CreditLimit; 
   exsr ApplyHold; 
endif; 

The business behavior has not changed. The program still evaluates the same condition and runs the same subroutine. What has changed is how clearly the source communicates that behavior. 

Replacing EXSR ApplyHold with a call to a procedure such as ApplyHold() may be a valuable next step, but that is refactoring, not just conversion. When you keep those changes distinct, the work gets easier to estimate, test, and explain to the business. 

Benefit 1: The Logic is Easier to See 

Readability is the first benefit most teams notice. A large part of maintaining an established RPG application is understanding existing behavior before changing it. 

A developer opening a fixed-format program must interpret the source layout while also tracing the logic. Which conditions apply to this operation? Where does the result go? Which indicators can the operation set? Where does a block begin and end? For someone unfamiliar with the program, or returning it months later, that extra layer of interpretation slows down the work. 

Free-format RPG removes much of that friction. Indentation makes nested conditions and loops visible. Statements have room for longer, more descriptive names. Related logic is easier to scan as a unit. During debugging or code review, developers can spend more of their attention on what the program is doing instead of first decoding how each line is organized. 

One thing worth noticing is that free-format RPG does not make complicated business logic simple, and it does not correct weak naming or poor structure. What it does is make that complexity easier to see. That gives developers a clearer starting point for maintenance today and for more deliberate refactoring later. 

Benefit 2: Control Flow Becomes Easier to Trace 

Fixed-format RPG is not necessarily unstructured, and free-format RPG does not eliminate operation codes. Operations such as CHAIN, SETLL, and READE remain part of modern RPG. Structured constructs such as IF, DO, and SELECT can also appear in fixed-format programs. 

The real problem is the control flow found in many long-lived applications. Older programs may rely on combinations of GOTO, TAG, conditioned operations, and nested subroutines. When execution repeatedly jumps between locations, a developer must reconstruct the path through the program before determining where a value changed or why a branch was taken. 

A syntax conversion may preserve those patterns in the first pass. That is often the correct choice when the immediate goal is functional equivalence. Automatically reorganizing control flow while also changing the source format introduces more behavioral risk and makes defects harder to isolate. 

Once the program is in free format, the team has a clearer foundation for targeted refactoring. Appropriate sections can be rewritten using IF/ELSEIF, SELECT/WHEN, DOW, DOU, FOR, and MONITOR/ON-ERROR. Subroutines can be evaluated individually and, where it adds value, subroutines can be replaced with procedures that have defined inputs and outputs. 

The result is a newer-looking syntax, and it also controls flow that developers can trace with fewer jumps and fewer hidden conditions. That makes debugging, code review, and future changes easier, but only where the team deliberately improves the underlying structure. 

Benefit 3: Conditions Become Explicit 

Numeric indicators are among the hardest RPG conventions for an unfamiliar developer to interpret. An indicator such as 90 communicates a state to the program, but it does not tell the reader what that state means. The developer must find where the indicator is set, determine whether the condition is normal or inverted, and trace every place where the same indicator is tested or changed. 

Consider a file lookup that uses indicator 90 to mean that no matching customer was found: 

C     Key           CHAIN     CustMast                           90 
C   90              EXSR      NotFound 
C  N90              EXSR      Process 
 

In free-format RPG, the file operation can be followed by an explicit condition: 

chain Key CustMast;

if %found(CustMast); 
   exsr Process; 
else; 
   exsr NotFound; 
endif; 

This version preserves the existing subroutines while removing the anonymous result indicator. The condition being tested is visible at the point where the decision is made, and the file name makes the intent more specific. 

Not every indicator will disappear. Applications may still depend on indicators associated with display files, printer files, or established interfaces. Where those indicators must remain, they can be mapped to meaningful names through an indicator data structure rather than referenced only by number. 

The key benefit is therefore “less logic governed by unexplained numeric state” and clearer names for the indicators the application still needs. 

Benefit 4: Business Intent is Easier to Express 

Long-lived RPG programs often express a single business action through several operations, temporary fields, and intermediate results. The code may work correctly, but the reader must assemble those steps mentally to understand the intended outcome. 

Free-format RPG gives developers more room to use assignment statements, qualified names, expressions, and built-in functions without fitting each element into a prescribed part of the source line. During modernization, that creates opportunities to replace multi-step patterns with statements that communicate the result directly. 

For example: 

FullName = %trim(FirstName) + ‘ ‘ + %trim(LastName); 

The inputs, transformation, and result are visible in one place. Functions such as %TRIM, %SUBST, %SCAN, and %REPLACEcan make similar string operations easier to recognize. Status functions such as %FOUND and %EOF can replace numeric result indicators where appropriate. 

These functions are features of RPG, not benefits created by conversion alone. A basic conversion may retain the existing sequence of operations to preserve behavior. Consolidating that sequence requires review, refactoring, and testing. 

The objective is also not to produce the fewest possible lines. A dense expression can be just as difficult to maintain as a long series of operations. The benefit comes from expressing each piece of business logic at the clearest useful level, with fewer temporary states for the next developer to trace. 

Benefit 5: A Clearer Path to Repeatable Testing 

Many established RPG applications were not designed around automated unit testing. Business rules may sit inside subroutines that also read files, update records, control a display screen, produce printed output, or change global indicators. Testing one calculation in isolation can require reproducing much of the surrounding application state. 

That structure reflects how the systems evolved and the development practices available at the time. Converting the source to free-format does not change it. A monolithic program in fixed format remains a monolithic program after syntax conversion. 

The opportunity comes during targeted refactoring. Teams can extract stable business rules into procedures with explicit inputs and outputs, separate database access from calculations, and reduce reliance on shared state. Once a procedure can be called independently, frameworks such as RPGUnit can support repeatable automated tests. 

Testing also matters during the conversion itself. A successful compile confirms that the source is valid; it does not prove that every business path still behaves correctly. Conversion programs therefore need regression testing that covers representative inputs, database conditions, outputs, and error paths. When existing automated coverage is limited, teams can begin with the most business-critical programs and the rules most likely to change. 

This produces more than a cleaner codebase. It creates a record of expected behavior that can be run again after future changes. That becomes especially valuable when the same business logic is exposed through an API, reused by another application, or prepared for a later modernization step. 

Benefit 6: The Learning Curve Becomes More Manageable 

Developers coming from Java, C#, JavaScript, or other commonly used languages will find much of free-format RPG familiar. Indented blocks, expressions, procedure calls, and control structures such as IF, FOR, and SELECT allow them to begin reading the logic without first mastering fixed column positions and result-field conventions. 

Removing that initial syntax barrier can make recruiting and internal cross-training more practical. Developers elsewhere in the organization can participate in code reviews sooner, follow the path through a program, and begin learning how the application supports the business. Showing candidates a well-structured free-format module also presents a more accurate picture of IBM i development as active software engineering rather than the preservation of an obsolete language. 

Free-format does not eliminate the real learning curve. New team members still need to understand RPG semantics, Db2 for i access, the IBM i operating model, application dependencies, and the business rules accumulated over years of change. A syntax conversion cannot explain why a particular exception exists or which downstream process depends on a field being updated in a specific way. 

That is why code conversion works best alongside documentation, consistent development standards, dependency analysis, and deliberate knowledge transfer. Free-format makes the application easier to enter. Those supporting practices help a new developer understand it well enough to change it responsibly. 

Benefit 7: Development Workflows Become Easier to Standardize 

Fixed-format RPG can be stored in Git, reviewed in a comparison tool, and edited in environments such as RDi. Converting the source is not a prerequisite for using those tools. The difference is how naturally the code fits into the team’s workflow. 

With free-format source, indentation can reflect program structure instead of column requirements. Editors have more room to display descriptive names and qualified fields. In a source comparison, reviewers can concentrate on the statements that changed rather than interpreting factors, result fields, and conditioning positions. Formatting conventions are also easier to document and apply consistently across the team. 

These improvements support more effective code reviews, but they do not create a complete development process on their own. Teams still need decisions about source ownership, branching, build automation, testing, approvals, and deployment. Moving code into Git without those working agreements simply places the same development habits in a different repository. 

Static analysis remains important on both sides of the conversion. Before work begins, it helps identify dependencies, shared files, calling relationships, and potential impact. After conversion, it helps developers understand the modernized application as it continues to change. 

Free format therefore improves the working surface around the code. It makes collaborative editing and reviews easier to standardize while allowing the underlying IBM i applications and business logic to remain in place. 

Turn the Benefits into a Realistic
Modernization Plan

The value of free-format RPG is that teams can remove unnecessary source constraints while preserving the IBM i platform and the business behavior they already trust. 

Turning that improvement into a responsible IBM i modernization plan starts with understanding the application. Before selecting the first program, teams should map its dependencies, identify external interfaces and shared files, document representative business scenarios, and decide which changes belong to conversion versus refactoring.

The best pilot should be important enough to demonstrate value, contained enough to validate the approach, and representative enough to reveal what a broader conversion will require. Its results can then inform development standards, testing requirements, effort estimates, and the sequence for the remaining applications.

What’s Next in This Series

In the next article, we will discuss what to do after a program is in free-format: how to identify useful refactoring boundaries, replace legacy patterns without changing business behavior, and establish practices the development team can apply consistently.

Frequently Asked Questions (FAQ)

Does converting to free-format change existing business logic behavior? No. A syntax conversion is designed to preserve existing program behavior while removing column-dependent source rules. It doesn’t automatically restructure subroutines, remove indicators, or separate business logic from database access; those are refactoring decisions made afterward.

What’s the difference between RPG conversion and refactoring? Conversion changes the source format from fixed to free without altering behavior. Refactoring is a separate, later step: reorganizing control flow, replacing subroutines with procedures, or isolating business logic, with its own scope, testing, and validation.

Do all RPG indicators disappear in free-format code? Not necessarily. Indicators tied to display files, printer files, or established interfaces can remain; where they do, they can be mapped to meaningful names through an indicator data structure instead of being referenced only by number.

What should be tested during and after conversion? A successful compile only confirms the source is valid; it doesn’t confirm every business path still behaves correctly. Teams need regression testing covering representative inputs, database conditions, outputs, and error paths, starting with the most business-critical programs. Once stable business rules are extracted into procedures with defined inputs and outputs, automated testing (frameworks such as RPGUnit) can make that regression coverage repeatable.

How do I decide where to start a free-format conversion? Start with a pilot program that’s important enough to demonstrate value, contained enough to validate the approach, and representative enough to reveal what a broader conversion will require.