[Stampo00]

The old pros are continuing to age out and retire or die. Places with COBOL systems want to keep their applications limping along instead of replacing them. The shortage of devs is only going to get worse. Remember when lock down started and some government systems built on COBOL started straining under the load? Rather than being dismissive, I'd encourage those with any interest at all to try to pick it up. We need folks to maintain it.

[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.

[thaumaturgy]

I do remember that, and as I pointed out in the thread at the time, New Jersey was asking for volunteers: https://www.cnbc.com/2020/04/06/new-jersey-seeks-cobol-progr...

My first dev job was COBOL on a Unisys mainframe. When the volume of "omg we need COBOL devs" articles got loud, I looked into what was available. The compensation graph for COBOL positions approximately matches those of any other dev job. You can do as well (or better) as a Python dev or Node dev or whatever.

The key to making more money is in specialization. The highest-paying jobs are looking for experience with specific combinations of technologies.

But being a Python dev has the added advantage of not having to deal with COBOL. ...speaking as someone who used Unisys' STRING/UNSTRING OS functions to implement input variable interpolation in COBOL because it has no native string operators or data type.

[BLO716]

Banks. Period.

[logical_ferry]

I don't work with COBOL but.I had my fair share of old legacy codebases. I sometimes think about how this crappy codebase first started out. Somebody somewhere had to write the first line of code. Was it exciting for them? Was it a sunny day? What did their office look like? Then I look at the codebase again and all this sentimentalism vanishes.

[bidirectional]

Working on incredibly boring retail banking systems which are a maintenance nightmare. If you want to work in a bank you'd get paid more working on front office software at an investment bank.