Most cobol systems have more code that doesn’t do anything vs code that actually does something.
What values do variables ROBERT1, ROBERT2 and ROBERT3 hold? Whatever ROBERT wanted.
And when that system is storing high-risk and/or sensitive data, do you really want to be the person who deletes code that you think "actually does nothing", only to find out it somehow stopped another portion of code from breaking?
The reason why these things still exist is business laziness. They don’t know and don’t care what cobol is or isn’t doing.
That's the thing - tor a risk-averse industry (most companies running COBOL systems belong here), being the guy who architected the move away from COBOL is a high-risk, high-stress job with little immediate rewards. At best, the move goes seamlessly, and management knows you as "the guy who updated our OS or something and saved us some money but took a few years to do it, while Bob updated our HR system and saved a bunch of money in 1 year". At worst, you accidentally break something, and now you have a fiasco on your hands.
It's never been a technical reason, it's the fact that most systems still running on COBOL are live, can't be easily paused, and there's an extremely high risk of enormous consequences for failure. Banks are a great example of this - hundreds of thousands of transactions per hour (or more), you can't easily create a backup because even while you're backing up more business logic and more records are being created, you can't just tell people "hey we're shutting off our system for 2 months, come back and get your money later", and if you fuck up during the migration and rectify it within in hour, you would have caused hundreds/thousands of people to lose some money, and god forbid there was one unlucky SOB who tried to transfer their life savings during that one hour.
And don't forget the testing that needs to be done - you can't even have an undeclared variable that somehow causes an overflow error when a user with a specific attribute deposits a specific amount of money in a specific branch code when Venus and Mars are aligned on a Tuesday.
Not a cobol professional but i know companies that have tried (and failed) to migrate from cobol to java because of the enormously high stakes involved (usually financial).
LLMs can speed up the process, but ultimately nobody is going to just say "yes, let's accept all suggested changes the LLM makes". The risk appetite of companies won't change because of LLMs.
Once sufficient people have purchased a house at the high price, it would be in their interest for prices to remain high. Corporate entities that buy up houses will actively lobby to make sure housing prices stay high, and the average Joe who paid that much for a house will be happy it stays that way.
I'd rather have a system that's compatible with both apple and android phones. A car is supposed to last decades; it's the absolute last place I want a walled garden.
look up owncloud if you're truly serious. you can set up your own personal storage with a rpi and spare hard drive that's 100% free of corporate greed and spying. you can also use the chance to set up a personal email server.
it takes work and money, but that's the price you pay if you're protective of your data.
Ah yes, men and women are physically built differently so trans women have an advantage because they can... grip the chess pieces better with their bigger hands, and crush the pieces/flip the table more easily due to their increased strength. Makes total sense.
In response, the US angrily condemned the move as "actions of aggressors looking to start a nuclear war that will cause the extinction of mankind", and arranged for missile launches off the coast of their neighbouring country.
And when that system is storing high-risk and/or sensitive data, do you really want to be the person who deletes code that you think "actually does nothing", only to find out it somehow stopped another portion of code from breaking?
That's the thing - tor a risk-averse industry (most companies running COBOL systems belong here), being the guy who architected the move away from COBOL is a high-risk, high-stress job with little immediate rewards. At best, the move goes seamlessly, and management knows you as "the guy who updated our OS or something and saved us some money but took a few years to do it, while Bob updated our HR system and saved a bunch of money in 1 year". At worst, you accidentally break something, and now you have a fiasco on your hands.