Enough COBOL

I spent two years as custodian of a COBOL batch I could read but never run — the only place it executed was the bank's machine, at night, against real money, which is a terrible place to learn. The vendor's development emulator cost more than my car. At some point I realized I didn't need COBOL, I needed our COBOL: the same few dozen verbs and patterns, over and over. So I started writing an interpreter in the evenings, with the batch's program listings as the requirements document.

You cannot safely understand a program you can only read, because reading tells you what you believe it does. I wanted to feed our batch programs realistic fixture files on my laptop, step through them, and watch what actually happened to each record. It was for me at first, then for the two colleagues who inherited pieces of the same custodianship, none of us COBOL programmers by upbringing.

All of it — the parser, the interpreter, the fake file system that serves fixture files in place of the bank's datasets, and the test suite, which is larger than the interpreter itself. Also the boundary: a list in the README of what it deliberately does not implement, which I maintain with more discipline than the features.

Interpreting rather than compiling was easy to choose — I wanted to step through execution, not produce binaries. The decision that kept the project alive was implementing only what our programs use: forty-one verbs at last count, no OO COBOL, no report writer, and anything unimplemented fails loudly with the source line rather than guessing. I also made decimal arithmetic exact from the start, using proper decimal types rather than floats, because a financial batch interpreter that rounds differently from the real thing is worse than no interpreter at all.

PERFORM. Its fall-through and range semantics broke my mental model of control flow three separate times, and I rewrote the interpreter's execution core three times to match — the test that finally pinned it was a fourteen-line program transcribed from a real batch step that executed a paragraph one more time than any of us predicted. When my laptop agreed with the mainframe's output on that program, that was the project's best evening.

It found one real thing: a rounding difference in an interest step between what the code did and what our wiki claimed it did, which we corrected in the documentation before it could mislead anyone during an incident. Both colleagues used it to learn the batch, and it became the onboarding exercise for my successor — break a fixture, watch it fail, explain why. Forty-one verbs, it turns out, is enough.

A colleague on the core systems team contributed fixture files and the healthy skepticism of a man who did not believe a laptop could run the batch until it disagreed with him and was right. The retired developer who once owned the batch reviewed my PERFORM semantics by email, which may be his idea of retirement.