221
[DISCUSS] IBM using LLMs to convert COBOL to Java
(techcrunch.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 23 Aug 2023
221 points (96.6% liked)
Technology
35152 readers
194 users here now
This is the official technology community of Lemmy.ml for all news related to creation and use of technology, and to facilitate civil, meaningful discussion around it.
Ask in DM before posting product reviews or ads. All such posts otherwise are subject to removal.
Rules:
1: All Lemmy rules apply
2: Do not post low effort posts
3: NEVER post naziped*gore stuff
4: Always post article URLs or their archived version URLs as sources, NOT screenshots. Help the blind users.
5: personal rants of Big Tech CEOs like Elon Musk are unwelcome (does not include posts about their companies affecting wide range of people)
6: no advertisement posts unless verified as legitimate and non-exploitative/non-consumerist
7: crypto related posts, unless essential, are disallowed
founded 5 years ago
MODERATORS
COBOL programs are structured very differently from Java. For example; you can’t just declare a variable, you have to add it to the working storage section at the top of the program.
That example doesn't sound particularly difficult. I'm not saying it'd be trivial, but it should be approximately as difficult as writing a compiler. Seems like the real problem is not a technical one.
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.
What.
Most cobol systems have more code that doesn’t do anything vs code that actually does something.
The grammar of COBOL + shit UI of mainframes means there is a shit ton of tribal anti pattern with each program. It is a pia to add fields and variables, so lazy programmers would just reuse something that wasn’t being used at that instant. Less work and more job security.
What values do variables ROBERT1, ROBERT2 and ROBERT3 hold? Whatever ROBERT wanted.
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.
I am struck by … conversion to … Java? Really??? lol.
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.
Org change vs vertical integration, which is worse and why in 500 words or less ;)
Pay now or pay later…the organization is going to get kicked in the nuts.
For industries that have the option, companies who got kicked in the nuts ten yrs ago are doing better today than those who are still waiting.
IBM should shoulder a lot of the blame, there really is no reason why COBOL couldn’t be phased out in place except it would hurt IBM market share so it is not exactly a “thing”. In place transition to RUST should just be another section of the zOS manual.