COMTRAN Reconstruction

A compiler for
a dead language

The manuals call it Commercial Translator; COMTRAN is the name it is known by, and neither manual prints it. was IBM’s business programming language for the 7090. No compiler survives and no source. What survives is two manuals, one from June 1960 and one from January 1962, and little else.

This compiler was rebuilt from those two manuals. For the one program whose printed output survives in them, it reproduces IBM’s listing byte for byte. It runs in your browser, and nothing you type leaves this page.

What this reconstruction rests on

One copy, one reader

Two manuals, 345 scanned pages, one copy of each. There is no second copy to settle a doubtful word against, and no second reader has been through them.

The judgment calls are marked

Where the manuals leave a question open, the language reference records the reading we chose and says plainly that it is a choice. Nothing is decided quietly.

The error severities are ours

The manuals list every message the compiler could print. They never say which ones stopped a run, so each severity on this page is this project’s own decision.

What IBM was building

Commercial Translator was aimed at the work computers actually did in 1960: payrolls, inventories and ledgers. You described your files first (each field’s name, how deep it sat inside a record, and a picture of the characters it held) and then wrote the procedure in something close to English. MOVE, ADD, IF, GO TO.

The machine underneath was the IBM 7090, which worked in words of 36 bits. Cards went in. A printed listing and a binary deck came out. The manuals call a field of letters and digits IBM’s own word of the period for letters and digits together; it is not a misspelling of alphanumeric., and this project keeps their spelling everywhere.

What we don’t have

What the manuals show is a language still being finished. The January 1962 reference is marked Preliminary, and its own appendix lists the features that had not been built. After that page, the paper we hold runs out.

Neither manual says how Commercial Translator ended, and this project does not rule on that from outside them. It is a scope decision, not a mystery: IBM published its own account, COBOL and Commercial Translator: A Comparison, form J28-6310, and a copy has been requested from the Computer History Museum. Until it arrives, this page will not tell you what it says.

Why rebuild it

COMTRAN is obscure even by the standards of retrocomputing. It was eclipsed before it ever became mainstream, and it disappeared with barely a trace. That is most of why I cannot stop thinking about it.

There is probably nobody alive who has written a program in this language and watched it run, short of someone with physical access to a working 7090. That is a strange thing to be true of a language IBM printed manuals for. It seemed worth fixing.

I am not building it for me. Researchers, code archaeologists, museum curators, a kid who has just found out that programs used to be holes punched in cardboard: they all need a way in, a foothold a deeper interest can grow from. That is what this page is for.

Correctness is the foundation, not the goal. There is a gap in the record of computing where this language should be, and you do not fill it by writing about it: you fill it by letting someone punch a card and compile it. The goal is that anyone can watch a COMTRAN program run, and that this outlives me.

One thing worth knowing before you judge any of it: every commit in the repository was written by a large language model, under my direction and held to my standards. How the reconstruction was done, and what it means for the evidence.

Compile a program

This is the compiler from the repository, built to WebAssembly and running on this page. Type into the deck, and the panels beside it show what the compiler makes of it. The program already loaded is the payroll sample printed in the 1962 manual: the one program whose source, compiler listing and object code all survive together in the manuals.

The card under the cursor

Twelve rows by eighty columns, the rows numbered 12, 11 and 0 at the top, then 1 to 9. The characters along the top are what the keypunch printed above the holes it cut; the holes are the part the compiler reads. Click a position to punch it, and the deck text follows. Cut a combination no character matches and the card leaves the character form for the punch form, which is what the deck format is for.

The deck

Card 1, column 1

What the compiler said

Eighty columns to a card. Columns 1 to 6 hold a serial number the 1962 compiler does not read, columns 7 to 72 hold the program, and columns 73 to 80 are never read at all. Lower case is punched as upper case, because the card character set has none.

Download the deck and you get the holes, not the text: the same card-image file the compiler, the deck tool and the card editor in this repository all read. Copy a link and the whole deck rides inside the address, so nothing you type is stored anywhere.

What the compiler made of it

Every listing on this page prints DATE 10/18/61 and TIME 2.45 in its page head. Those are the sample listing’s own values, pinned so that one program always prints the same bytes, whoever compiles it and whenever.

What comes next

Today this page compiles: it reads your deck, checks it, lays out storage and prints the listing. There it stops, because the compiler stops there too. Three things stand between that and a program that runs.

Code generation

The verbs (MOVE, IF, GO TO and the rest) become 7090 instructions. The compiler already lays down the data, which is the constants and the space each record needs. The procedure text is the part still being built, and it is not being guessed at: the manual prints this sample’s assembled object program in full, so there is a right answer to check against, line by line.

The machine

A 7090 emulator, word-exact, to run those instructions on. A draft core already reads 43 instructions harvested from the manuals. It hardens alongside the code generator, because each one is the other’s test.

Running it

The input and output runtime, reading a tape and writing a report. Then the test that ends the project: compile the payroll sample, run it, and reproduce the report the 1962 manual prints with it. Byte for byte, the way the listing on this page already matches.

Each of those arrives here for free, because the page holds no compiler knowledge: it asks the compiler and prints the answer. The Code panel fills itself, and a Run button appears once there is something to run.

There is no timetable, and this page will not invent one. It takes as long as the evidence takes. What is built, and what is not, or the project handover, with the state of every milestone.

Going deeper

Everything on this page is a reading of a document you can go and check. The repository is the academic artifact; this page is only the door.

If a reading here is wrong, the page it came from is one click away. The page number is the useful thing to send.