> Mainframe systems are facing a critical shortage of developer workforce as the current generation of COBOL developers retires. Furthermore, due to the limited availability of public COBOL resources, entry-level developers, who assume the mantle of legacy COBOL systems maintainers, face significant difficulties during routine maintenance tasks, such as code comprehension and defect location.

Old stuff is hard to maintain? Who would have thought!

This myth of a Cobol developer shortage really has a lot of legs. I personally know of hundreds of former Cobol developers who moved on after their jobs were offshored over the past 12 years. If Cobol paid current salaries, a lot of former Cobol developers would be back. But companies don't pay, and developers stay away.

Note that COBOL does exist outside of mainframe systems. Peoplesoft is a fairly popular HR Payroll package and works on what they call distributed systems as well (windows Linux Unix rtc). I've worked on various peoplesoft systems over the years and they include a mixture of "modern" but proprietary languages (peoplecode, application engine) as well as legacy (Cobol, sqr). Currently on a project that implements them on Unix,serving 350k self service employees. Data issues are indeed our number one type of defect. I wonder how much that is language vs environment that language is typically deployed - I.e. Our own reasons for data being our number one issue seem external, but maybe there's data handling capabilities, or lack thereof, that we are blind to.

Doesn't look like it's mentioned here, but expense of the COBOL toolchain has got to be an issue for its uptake.

Paid toolchains have essentially failed in software engineering. There are some hybrid business models in game engine toolchains, but moving towards more free/open/flexible systems has resulted in huge growth. You can pay for support from certain companies, but that's not quite the same.

If you want to run COBOL, you typically need to buy a compiler, buy specialist hardware, and buy an IDE. There are open COBOL compilers but COBOL compilers have compatibility issues worse than browsers so particular compilers do matter.

The most modern and accessible COBOL development that I'm aware of is JVM/CLR COBOL developed in Visual Studio/Eclipse. You can even run it on Android! But you have to buy the whole toolchain, and it's very much "call us for pricing", not low prices and putting in a card number.

This ultimately prevents new people from joining the community as open/free compilers and toolchains are essentially table stakes at this point, and that means the community is only going to shrink.

COBOL is an extremely easy language to learn.

Companies needing COBOL programmers find it easier to train up someone in COBOL, rather than finding a pre-existing COBOL programmer.

I learned COBOL in a month.

The only reason a company can't get COBOL programmers is because programmers want to work in Python or Java or anything that looks good on a resume for the next job. COBOL is pretty much a dead end, a hiring person is going to look at your last job and see COBOL and say no thanks. Not all companies, but why take the risk?

If you're still working at a place that still maintains COBOL code, you should quit and come back as a much better paid contractor. Don't waste your retirement doing that for less than a few hundred bucks an hour.

And if you're a young person, don't waste your youth on the dead-ends of the past. You can make a million bucks in a year if you're really good at all that AI stuff!

"Contemporary COBOL". At least they didn't say modern COBOL, or it will be an oxymoron.