Every company that sells legacy modernisation says the new system will behave exactly like the old one. Few show the evidence. So we ran a COBOL modernisation in the open, on an application anyone can download, and compared the old and the new line by line and record by record.
Syntaxe makes Sovereign, which moves organisations off old software they cannot switch off. It reads the code, rebuilds it in modern code, and proves the rebuild behaves the same as the original before anything is switched over.
A credit card system anyone can download
CardDemo is a credit card management system that Amazon Web Services publishes on GitHub as a sample mainframe application. It is written in COBOL, with the job scripts and file layouts of a real mainframe system, and it does what a card issuer’s back office does: it keeps accounts, cards and customers, posts each day’s transactions, calculates interest, and prints reports and customer statements.
CardDemo has 31 online screen programs and 13 batch programs that do the overnight work. This case study covers the 13 batch programs.
Old and new, run side by side
Sovereign read the 13 batch programs and rebuilt each one in modern code. Then we ran every original program and its rebuild on the same input and compared everything they produced:
- every line each program printed,
- every record of every file each program wrote, byte for byte.
The originals ran off the mainframe, compiled with GnuCOBOL 3.2, a widely used COBOL compiler.
We ran each comparison on CardDemo’s own data, and again on three sets of generated data that reach the largest and smallest values each field can hold. Edge values are where rewritten systems usually go wrong, so that is where we tested hardest.
All 13 batch programs match
| Program | What it does | What was compared |
|---|---|---|
| CBTRN01C | Checks each day’s transactions | 1,807 printed lines |
| CBTRN02C | Posts the day’s transactions to the accounts | 54 printed lines and four files (262, 38, 50 and 100 records) |
| CBTRN03C | Prints the transaction report | 267 printed lines and the 451-line report |
| CBACT04C | Calculates interest | 152 printed lines and two files of 50 records |
| CBSTM03A, with its file module CBSTM03B | Produces customer statements, as text and as web pages | A 1,212-line statement file and a 6,082-line HTML file |
| CBEXPORT and CBIMPORT | Export all the data to one file and load it back | 462 export records, then five files loaded back |
| CBACT01C, CBACT02C, CBACT03C, CBCUS01C | Read and list accounts, cards, cross-references and customers | Every printed line and every file written |
| CSUTLDTC | Checks dates, including leap days and invalid dates | Eight test cases with every result returned |
| COBSWAIT | Waits a set time | The delay it sets |
On every run, on every data set, the rebuilt program printed the same lines and wrote the same records as the original. One command repeats every run.
What we changed, and why
A proof is only worth something if it says plainly what was changed.
- CBEXPORT and CBIMPORT do not compile as published. A four-line fix makes each one compile; the rest of each program is CardDemo’s code.
- CBSTM03A reads the mainframe’s own memory to print the job’s name, which only exists on a mainframe. Those lines now take the same names from the job script.
- IBM-only routines, such as a date service, are replaced by the same equivalent stand-ins on both sides.
- Interest on real balances. CardDemo’s sample balances are all zero, so its interest program never calculates any interest on them. We also ran it on a copy with non-zero balances. It matches on both.
Every change is listed in the proof report.
What comes next
The 31 online screens, and CardDemo’s database and messaging versions, are the next scope. The same method applies: the old and the new run side by side, and every difference is shown.
CardDemo is written in COBOL. Sovereign is built for the whole range of legacy languages organisations run: COBOL, Fortran, PL/I, MUMPS, Perl, REXX and ColdFusion are rebuilt and proven in the product today, each checked against its own compiler or interpreter. For the scale of what this means, see how Sovereign answers the 844-year COBOL calculation.
What this means for your system
If you run a system you cannot switch off, this is the kind of evidence to expect before anything changes:
- Your own system, compared with itself. The old programs and the new ones run side by side on the same inputs, and every difference is shown with the inputs that caused it.
- On your site. Sovereign runs inside your network, with no AI model and nothing sent outside.
- Proof you keep. The comparisons come with the inputs and outputs, so your own team can check them again without us.
Our guide on how to prove a rebuilt system does exactly what the old one did shows how to judge any supplier’s proof, including ours.
The first step
The first step is an assessment. Sovereign reads your code and gives you a report: what the system does, where the risk is, and what moving off it would take. The scope is fixed and agreed before any work starts, and you decide afterwards whether to go further.
0 comments