[thr0wawayf00]

> We need folks to maintain it.

Beware, maintaining those systems is absolute hell and the companies experiencing exodus are working their people into the ground because the workload is crushing them and they can't find replacements.

A good friend of mine is an engineering director at a company that runs a massive COBOL mainframe platform and he always half jokes with me about picking it up. The money isn't that great at his company and the problems they have maintaining the system just blow my mind. The entire company sounds fundamentally unsustainable long term but they're running critical payments infrastructure.

[masukomi]

as an outsider (and thus potentially ignorant of pitfalls): I'm a big fan of the strategy to add transpilers to modern languages so that we can start writing new code in them, have them output COBOL, and then eventually have enough of the codebase written in the new lang to swap over to it instead.

I'm thinking of the Elixir->COBOL like this: https://github.com/TheFirstAvenger/cobol_to_elixir

Was speaking with the author about a year ago and he was having really good success with it.

[karmakaze]

The example link goes COBOL->Elixir.

I like this idea of writing Elixir and outputting COBOL. That way it can interface with the operating environment (CICS, IMS) exactly as a natively written COBOL program does. Not that COBOL syntax is particularly hard to learn one by one, but as a whole isn't very memorable. Why learn a programming language with peculiarities like a natural language when I can use something concise that translates to it? There may not need to be a step to eliminate the COBOL output step any more than a language that uses C or js as a target.

I've only seen two kinds of CICS programs in the wild: 1. screen I/O using preformatted BMS maps, 2. transactional with input buffer and output buffer. A third kind was one I wrote for sending dynamically generated terminal stream data for a hypertext online documentation system.

Any of these could be written in Elixir with appropriate libraries and translators. The company I worked at generated the BMS maps and COBOL source from assembling program components with an inclusion/override macro processor and wysiwyg editors--think Visual Basic for mainframes targeting both CICS and IMS.

[jhugo]

This again focuses on the language rather than the environment. The real issue is all the legacy integrations, and the runtime environment, not the language. A transpiler is solving the easiest part while leaving all the difficult problems unaddressed.

[p_l]

The big issue is that for considerable portion of extant COBOL software, you have to deal with entrenched runtime environment. Purely batch processing COBOL might be easier to move to newer languages... And possibly was already picked for rewrite.

Where you're going to hit major issue is with COBOL running under the likes of CICS or IMS, where sure, you can use some more recent languages, but what you'll get in the end will be possibly even worse because now you'll have to find Java programmer who knows CICS.

And CICS or IMS aren't that easy to replace.

[ElectricalUnion]

A transpiler/compatibility layer is usually fine, but what you (probably) want instead is a IBM VSAM, IBM JCL, and IBM CICS transpiler/compatibility layer instead - COBOL by itself is very simple and we have working compilers for it already; JCL, VSAM and CICS however, not - that's where the real complex, distributed and hard to reason about parts are.

[nebula8804]

>running critical payments infrastructure

Please tell me its not a payroll company.

[thr0wawayf00]

No, it's one of the largest credit card processors in the country.

[krylon]

I'm not sure if that makes me feel better.