Modernising without rewriting

"Modernisation" is a word that in many departments means "rebuild", and rebuilding an application that has worked for twenty years is the worst risk-to-benefit choice available.

The honest starting point is a different one: code that has run for twenty years has already passed every possible test. It contains dozens of special cases nobody remembers, which are there because they really happened. Rewriting it means losing them all and rediscovering them one at a time, in production.

Modernising, then, means changing the parts worth changing, in an order that lets you stop at any point without having left things half done.

What actually counts

Not everything that looks old costs anything. The three things that genuinely cost are these.

Duplicated logic. The same rule written in twelve programs, which when it changes has to be changed in twelve places and gets forgotten in one. It is the largest cost, and it has nothing to do with the age of the code.

Being unable to talk to the outside. An application usable only from green screens cannot serve a website, an app, a supplier. It is the constraint that blocks new projects, and it is nearly always the real reason somebody proposes rebuilding everything.

Code nobody can read any more. Not "old": unreadable. A well-written column-based program can be read; a program with forty indicators and six-character names cannot, and the cost is paid on every change.

The order that works

1. Extract the logic into procedures

This is the first step because it touches nothing and enables everything else. The duplicated rule is written once as a procedure inside a service program, and programs start calling it — one at a time, whenever you happen to be in there.

dcl-proc calcNetAmount export;
  dcl-pi *n packed(11:2);
    amount packed(11:2) const;
    rate packed(5:2) const;
  end-pi;

  return amount - (amount * rate / 100);
end-proc;

From here on the same procedure is callable from an RPG program, from a web service, and — by declaring it as an SQL function — from a query. Same rule, one place.

2. Make it callable from SQL

An existing procedure or program can be exposed to the database:

CREATE PROCEDURE PRODLIB.CLOSE_ORDER (IN NUMBER DECIMAL(7,0))
  EXTERNAL NAME 'PRODLIB/CLOSEORD'
  LANGUAGE RPGLE
  GENERAL;

From then on anyone who speaks SQL — a report, another system, a Java program — can run that logic without knowing there is RPG behind it, and without anybody giving them access to the files.

3. Expose the services

Three routes, answering different needs:

• Integrated Web Services — the system exposes a program or procedure as a REST or SOAP service, through configuration and without writing network code. The most direct route when a function has to be callable from outside.
• SQL APIs — whoever connects over JDBC or ODBC calls the procedures above. The simplest route when the other end already knows how to use a database.
• XMLSERVICE — calls programs and commands from PHP, Python, Node and other languages. The route used by web applications written off the system that need to reuse the logic inside it.

4. Replace the interfaces, not the engine

5250 screens can be changed without touching the programs beneath them: either with automatic screen modernisation, or with Open Access, which lets an RPG program written for a display file be driven by another interface — a browser, an app — without changing its logic.

What not to do

Do not rewrite in another language "because RPG is dead". It is not, the compilers gain new capability at every release, and the cost of a complete rewrite is paid all at once against a benefit that will show over years — assuming the project finishes, and most do not.

Do not convert to free-form as a project in itself. Do it when you are in a program for other reasons. On its own it produces an identical application that has to be tested from scratch.

Do not start with the hardest part. The first piece to modernise is the one touched most often, not the one that frightens most: you need a result visible within weeks, or the project loses support before producing anything.

Do not do it without measuring. "How many times a month is this program touched", "how long does the close take", "how many errors come from this area" are numbers you can have before and after. Without them, modernisation is an opinion, and opinions do not survive a budget cut.