The program

The program was originally generated using AS/SET and subsequently converted from RPG to RPGLE. Like many generated applications, it contains a significant amount of working business logic alongside patterns inherited from the original development tool.

The source contained:

• 2,858 lines
• 1,769 executable lines
• 955 comment lines
• 19 identified subroutines
• Six High-complexity hotspots
• A maximum nesting depth of 9

This was not a small demonstration program created specifically for the exercise. It was an established application program with enough size and complexity to provide a meaningful modernisation example.

The original RPG Metrics results

The initial scan showed that 987 executable lines contained syntax that would require attention before the program could become fully free format.

The compatibility figure immediately provided a useful conversion baseline. More than half of the executable source contained syntax that could not remain unchanged in a full-free program.

However, compatibility was only part of the picture. The hotspot analysis also identified six routines with High complexity. The most complex routine had a Cyclomatic Complexity value of 46.

Converting the syntax in controlled stages

Rather than attempting to rewrite the program and change its business behaviour at the same time, the source was converted in stages.

1. Convert the calculation specifications to extended Factor 2 format.
2. Replace older parameter-list and calling conventions.
3. Complete the conversion to full-free RPG.
4. Rescan the source after each significant stage.

This approach separates the mechanical conversion from later application improvement. It also makes it easier to verify that the program continues to produce the same results before any business logic is changed.

Compatibility improved dramatically

The percentage of incompatible executable source reduced at each conversion stage.

That is a clear and worthwhile result. The completed version contained no active source lines identified as incompatible with full-free RPG.

The final compatibility scan also ignores old syntax contained only in comments. This prevents historical or commented-out code from incorrectly making a full-free program appear incompatible.

But the structural complexity did not disappear

The syntax conversion was successful, but it did not automatically simplify the underlying program.

The converted source still contained:

• Six High-complexity routines
• Several Moderate-complexity routines
• A maximum nesting depth of 9
• The same principal areas of concentrated decision logic

The final two conversion stages produced the same total Cyclomatic Complexity value of 327 and the same hotspot and nesting results. Removing the remaining incompatible syntax made the program fully free format, but it did not alter its underlying control flow.

This is the key distinction: converting syntax changes how the program is expressed. Refactoring changes how the program is structured.

Why the complexity total changed

The whole-program complexity value increased during conversion, but this should not be interpreted as evidence that the conversion made the application worse.

Some operations in the generated source handled conditions implicitly. During conversion, those conditions became explicit RPG statements such as if %error;. Once expressed as visible decision points, they could be counted by the analyser.

The converted program also moved one section of source into a /COPY member. Because the reports measure the source presented to the analyser, whole-program totals from the original and converted versions are not perfectly like-for-like.

For that reason, the most reliable comparison is not simply the headline complexity total. It is the persistence of the same hotspot routines and nesting patterns through the conversion.

What about the Maintainability Index?

The Maintainability Index also changed between versions, but we would not use that number alone to claim that the conversion improved or damaged maintainability.

Generated conversion can expand source, expose previously implicit decisions and alter the balance between executable lines and comments. All of these affect the Maintainability Index even when the program continues to perform the same work.

The index remains useful as a baseline and trend measurement, particularly when comparing repeated scans of the same source structure. It needs more care when comparing substantially different representations of the program.

Phase one: achieve a clean conversion

The purpose of the first phase is straightforward:

• Remove incompatible syntax
• Preserve existing business behaviour
• Compile and test the converted application
• Establish a repeatable metrics baseline

This phase should avoid unnecessary functional changes. Combining conversion and business enhancement makes testing harder because a changed result could have been caused by either activity.

Once the converted application produces the same outputs as the original, the syntax-modernisation phase has achieved its objective.

Phase two: improve the application structure

The RPG Metrics hotspot report provides a practical starting point for the second phase.

Instead of attempting a wholesale rewrite, the development team can concentrate on the routines carrying the greatest technical risk. In this program, that means examining the six High-complexity routines and the sections with the deepest nesting.

Potential improvements could include:

• Separating large routines into smaller procedures
• Reducing deeply nested conditional logic
• Replacing repeated processing with reusable procedures
• Making error handling more consistent
• Separating user-interface, database and business logic
• Adding focused tests around high-risk decision paths

Each structural change can then be rescanned. This makes it possible to demonstrate whether complexity and maintainability are genuinely improving rather than relying on the source simply looking more modern.

The practical lesson

Full-free RPG is a valuable destination, but reaching it is not the end of application modernisation.

In this example, conversion reduced incompatible executable code from 55.79% to zero. That is a measurable success. At the same time, the principal complexity hotspots and maximum nesting depth remained.

The conversion produced modern RPG syntax. The metrics showed where the next modernisation work should begin.

That is why we favour a two-phase approach:

1. Convert first, preserving behaviour and removing obsolete syntax.
2. Improve second, using evidence to target the areas where structural change will provide the greatest benefit.

Modernisation should not be judged solely by whether the source compiles as full-free RPG. It should also make established applications easier to understand, test, maintain and safely enhance.

Assess your own RPG applications

RPG Metrics analyses RPG source locally and produces measurements covering complexity, maintainability, comments, nesting, hotspots and full-free compatibility. Your source code remains within your own environment.

For a structured review of an established application, see our IBM i RPG Code Health Assessment or contact KDP Software to discuss your modernisation plans.