Converting RPG to Java

Two Changes, One Date

When the first month-end close after cutover produces a total that does not match the IBM i's last run, the question is which change caused it - the new platform or the translated code - and the output cannot answer it. Your RPG developers cannot check the logic, because the logic is now Java. And the rollback is not one change but both: the platform move may have been sound, and it comes back anyway, because after the fact it cannot be separated from the rewrite.

Of the two changes, the rewrite is the one that fails quietly. Translated Java keeps RPG's design - global fields as class members, indicators as booleans, keyed reads emulated through the vendor's runtime library - and the reasoning behind the logic is not in the files, because it was never in the RPG either. A parallel run proves the paths the test data exercises. Year-end code that first runs the following December gets its real test in production, months after the vendor's engineers have left.

Move the Platform First

Only one of the two changes has a deadline. The hardware refresh, the license renewal, the datacenter exit - whatever set the date - is a platform problem, and the platform can change with the code held constant. Triton RPG compiles the RPG you have - RPG II, RPG III, ILE RPG IV, fixed or free format - to JVM bytecode, the way the compiler on the IBM i compiles it to a program object. The source, the team maintaining it, and the screens your users know stay as they are; the machine underneath is the only change.

Testing one change is a different job from testing two. The code on both sides is the same source, so the IBM i's own output is the acceptance test: the same inputs through both copies, the outputs compared, and any difference attributable to the platform and nothing else. There is no cutover night, either - programs move a few at a time, and the ones that have not moved keep running where they are.

The move is also narrower than a conversion, because it does not take everything with it. Db2 for i stays, and the compiled programs reach it over JDBC with the jt400 driver, reading the same tables as the programs still running natively. The CL, the scheduler entries, and the journaling stay on the IBM i. A conversion that promises a decommissioned machine has taken on replacing all of that too, and none of it is RPG.

The Rewrite Can Wait

With the programs off the hardware, the rewrite has no date attached to it. It proceeds module by module, when a business change makes a program worth rebuilding, with the running RPG still there to check against. Modules nobody has a reason to rewrite stay in RPG. Java developers hired in the meantime work against the compiled programs as .class files - a set of RPG programs went behind a REST API with 310 lines of ordinary Java.

When Converting Is the Right Answer

Some organizations convert deliberately: the plan of record is no RPG on staff within a few years, and the Java team that will own the programs is funded and being hired now. Splitting the work does not block that plan. It changes the order - off the hardware first, rewritten after, one module at a time, with each module's output checked against RPG that is still running.