Google Alerts sent me a link to an article which I can’t find on this machine. SAD. But the thing that caught my eye was the claim that someone had to convert their COBOL to “something more modern” for Operational Flexibility. Which, to be polite, is nonsense.

A COBOL program, compiled, is just like a compiled Rust, Go, C, or C++ program. It’s just a program. It has fewer external dependencies than most “modern” programs. And it is as efficient as programs written in any of the above or their many language friends. So, operationaly it is no different.

A compiled COBOL program runs very nicely on a server, a virtual machine (VM), or in a container. Of course that means it runs nicely on The Cloud!

But We Get It

The Operational Flexibility part refers to the platform they’re running on. The mainframe people harp about how easy to use their stuff is and how efficient and how wonderful because it all has that 60 year old Eames designed logo on it. Only that last point is valid … maybe.

The mainframe is scrambling to look modern. But it is weighed down with non-COBOL legacy baggage. Getting off the mainframe is 10% COBOL and 90% Everything Else (my numbers, may be as low as 80:20 … everything is 80:20, no?). Some of that legacy baggage has been ported to Linux and The Cloud. That helps. The rest, not. And even things that sound like they are compatible only rhyme … close but nope!

What To Do?

Lots of the COBOL applications are simple “batch” applications that use the outputs of much more complicated applications. They move to the platform you want to be on really easily. So move them! and sort out the processes and procedures needed to bring their operational requirements into the 21st Century. It’s a start.

Then call us for help with the rest