[danpalmer]

As I understand it, the field is going in the other direction, namely JVM/CLR COBOL. This means that companies can migrate their COBOL codebases to “commodity hardware”, save on mainframe costs, and then progressively refactor into Java/.NET replacing bits of COBOL piecemeal.

The main company I’ve heard of doing this is MicroFocus, they have all the dev tooling for it for the major IDEs, compilers, etc.

One of the main things that complicates the problem, again as I understand it, is that there is no official COBOL spec. There are several versions from several vendors, but compilers have to account for mainframe hardware bugs, so there are many different targets that have to be supported. Most companies want a different, specific, set of compiler features.

[jasonhansel]

Hmm. I'm interested in making a compile-to-COBOL language only because that way a company could incrementally migrate an old COBOL codebase to the new language. In other words, the new code (which compiles to COBOL) and the old code (written in COBOL) would be fully interoperable, sharing the same data types, calling conventions, etc.

[danpalmer]

Yeah, and this makes sense, but there are multiple problems with COBOL on mainframes – the COBOL, and the mainframes.

COBOL and mainframes have quite a different programming and system administration model to what we expect with servers. Lots of concepts are quite different, built up from a world of mainframes and terminals, tapes, batch processing, etc. Concepts like users, operating systems, files, networking, parallelism, programs, databases, are all quite different, and all of these differences cause companies problems in training users, and creating nice new software that works in ways people expect now.

Creating a, for example, JavaScript to COBOL compiler is probably not fully possible. You may be able to transliterate it, but you would essentially be writing a COBOL program in JavaScript syntax – not using Node libraries and writing React components. This reduces many of the benefits.

The alternate approach is that you take your COBOL and compile it to work in the JVM. You get a JAR out that you can run on your regular servers that are already running your other JVM software. There is probably a significant runtime built into that by the compiler that translates some mainframe concepts into modern concepts, but that's fine because you haven't had to rework your COBOL. Then, you can progressively pull out modules, rewrite in Java, and reference those from the old COBOL code. You don't need lots of training in mainframe concepts, you don't need to spend millions of dollars a year on your mainframe, and you can write new code in Java.

The US Department of Defence have taken this approach one step further, and are actually writing a compiler from COBOL to Java. It's not fully automated, but with not too many developer-hours, they can turn significant chunks of COBOL into reasonably good quality Java, over the course of several stages.

Your idea is a good one, and worth experimenting with maybe, but I think the best approach for the migration away from COBOL for large businesses (and only large businesses use it) is the other way around.