Face it, there is nothing that can replace COBOL

[zamroni111]

It's not the code, it's the business logic embedded inside it that isn't documented anywhere else. That's one reason state unemployment system rewrites failed. Then there is the problem of lost source code, because the executable you are running was created from input that might not be around anymore. Don't laugh, I've seen it.
Don't forge the portions that were written in assembler for performance. Another language to learn. The JCL that ties these batch programs together. The CICS or IMS that drive the green screens. It's never one month to learn it all. I worked at a place that was going to get rid of the mainframe in the 1990s. Three decades later, they did it, by replacing the systems, not by rewriting COBOL programs.

I'm still laughing at the idea of using Java. Does nobody remember Sun releasing new versions that broke working code? You could keep running the old versions, with their newly discovered vulnerabilities, if your IT Security guys let you. Keep an updated resume, in case you get hacked. COBOL was dull, boring, and nearly immutable.

I heard same reasoning that the software is too complex etc on my first job on 2003.
if cobol and assembly based software from 1900s can run the business logic, that means modern language e.g. java etc. also can.

and how come the business logic can't be replicated?
just analyze all the inputs and outputs to design the new system and do proper & complete tests.
I have done successful telecom realtime billing migrations and above was the key.

as for java bug, simply use LTS version that are more than 1 year old.

 

[hwertz]

I've been a developer and dev manager working across all sectors from Fintech to Aerospace and Defence for 40 years and have had (thankfully) no contact with Cobol for the last at least 35 of those years.

Yeah, I do believe this is HIGHLY concentrated in accounting type tasks; banks, and payroll systems for the types of large companies and government agencies that would probably be running something like SAP if they'd made their payroll electronic more recently.

 

[GreenNova343]

I feel this issue is completely self-inflicted by companies. It's not as if the writing hasn't been on the wall for decades regarding COBOL. COBOL, invented in 1959, was already on its way out the door in the 1990s when I was in college. I mean that COBOL wasn't even being taught in schools by the mid-90s, not just that it was out of fashion. This means governments and corporations had over 25 years to address this issue. Instead of planning ahead and creating alternatives, they chose to bury their heads in the sand. The right approach would have been to continuously upgrade their technology, but instead, they rested on their laurels and feel victim to the sunk cost fallacy.

FYI, this is the exact same issue seen with civil infrastructure, such as bridges, roads, and water treatment. Once the cost is sunk, there's reluctance to pay for upkeep or upgrades. Then, when it starts to fall into disrepair, they throw their hands up and claim it is almost impossible to fix and if they can how massive the cost will be to fix it.

That said, I genuinely believe generative AI is the key to solving this challenge. It has proven great at "translating" different forms of text, and I see no reason it can't translate COBOL into another programming language. Obviously, it won't be a one-to-one translation, but there's a practical solution there. Does this help with the old mainframe computers and other hardware? Likely not, but that just reinforces my previous argument that they need to upgrade and pay the cost. Yes, they are going to take a financial hit, and their stockholders may punish them, but the alternative is worse if they can't maintain their systems.

Not quite correct. When I graduated with my programming degree in 1998, COBOL was still a major part of the curriculum (including a CICS course), simply because not only was the Y2K bug an issue, but because so many banks, state agencies, & other entities were running COBOL on their servers at their relatively local HQs ("local" as in within a 1- or 2-hour drive of the campus). At least two of the state agencies involved are still running their COBOL-based applications.

Probably the biggest issue is that it seems like most programming languages are geared towards dynamic or real-time processing, but the COBOL-based applications are geared for batch processing. Some of that is not due to a "we picked batch processing because that's what worked back then", sometimes it's because there are regulations involved. So are there any good programming languages that can provide the same results as COBOL, and either deliver the results faster or do so without requiring a lot more resources to run?

 

[zamroni111]

Not quite correct. When I graduated with my programming degree in 1998, COBOL was still a major part of the curriculum (including a CICS course), simply because not only was the Y2K bug an issue, but because so many banks, state agencies, & other entities were running COBOL on their servers at their relatively local HQs ("local" as in within a 1- or 2-hour drive of the campus). At least two of the state agencies involved are still running their COBOL-based applications.

Probably the biggest issue is that it seems like most programming languages are geared towards dynamic or real-time processing, but the COBOL-based applications are geared for batch processing. Some of that is not due to a "we picked batch processing because that's what worked back then", sometimes it's because there are regulations involved. So are there any good programming languages that can provide the same results as COBOL, and either deliver the results faster or do so without requiring a lot more resources to run?

All modern programming languages can do what cobol can.
In 2008, I made Java program to process DB dump files of 24 millions telecom subscribers and their account history records.
It was done like in 3 hours by 8-core sun e2900 server.

those companies need good solution architects to migrate the cobol to modern 64 bit app.