Face it, there is nothing that can replace COBOL

[emorphy]

The big picture: COBOL is decades old yet it still dominates our IT ecosystem and even the economy. But a replacement must be found, if only because the number of developers that can work on the language is dwindling. Is AI the answer?

It's 60-plus years old and there are better and more modern programming languages out there, but COBOL (Common Business Oriented Language) is still with us. Not only is it an active part of the IT ecosystem, but it dominates it when it comes to the use of mainframe computers.

According to various statistics, COBOL supports over 70 percent of Fortune 500 business systems and touches up to 85 percent of all business transactions. Mainframes (which commonly use COBOL) are widely used by large enterprises, particularly in sectors that require robust data processing capabilities. You could go so far as to say that COBOL is a lynchpin in the world economy.

Systems powered by COBOL handle $3 trillion of daily commerce. COBOL handles 95 percent of all ATM card swipes and it makes 80 percent of all in-person credit card transactions possible. "The second most valuable asset in the United States – after oil – is the 240 billion lines of COBOL," says Philip Teplitzky, who's slung COBOL for decades for banks across the US.

And this is a big problem.

For starters, there is a shortage of IT workers who can work with COBOL, a fact state governments became painfully aware of during the pandemic when they had difficulty finding technicians skilled in COBOL to work on their unemployment systems, which had become overwhelmed by the sudden spike in claims. COBOL and the mainframes they run on are also clunky and difficult to upgrade to support modern business activities like mobile.

All of this makes COBOL "a significant operating risk," according to Maryland's Information Technology Secretary Katie Savage. "For me, we're making the business case around why from a security and workforce development perspective, we have to upgrade," Savage said at the Google Public Sector Forum last year.

It persists, though, for a variety of reasons. Mainframes, as antiquated in IT years as they are, are still prized for their resiliency and security and, more importantly, are still able to carry on with the massive batch processing for which they were designed. These IT resources also represent a significant sunk cost for the businesses that have them and making the case for a modern platform at the cost of millions of dollars is difficult. Also, many software providers' toolsets can interface with COBOL, which makes maintenance possible. It's even possible to move COBOL to the cloud.

Most fundamentally, though, COBOL persists because it has no obvious successor. Sure, there are modern languages like Java or C# that could replace COBOL but for all the reasons above businesses and governments are not moving forward with them.

One bright spot emerged last year when IBM unveiled a generative AI tool to help developers facilitate faster translation of COBOL to Java.

But even this solution is probably not the answer, at least not yet. It still requires developers, and remember: the numbers who are trained on COBOL are rapidly diminishing. The developer may still need to perform some minor editing of the code that the AI provides, Skyla Loomis, IBM's Vice President of IBM Z Software, says.

Furthermore, as Gartner Distinguished Vice President and Analyst Arun Chandrasekara points out, IBM has no case studies to validate its claims. "AI generation is an early-stage technology that takes time to perfect. I'm sure they have checks and balances in place to address this situation, but I prefer to take the 'wait and see if it works' approach."

Basically, cost-conscious companies are mindful that it is still early days for generative AI. On the other hand, COBOL has been around for decades.

Permalink to story.

https://www.techspot.com/news/101900-face-there-nothing-can-replace-cobol.html

 

[Theinsanegamer]

COBOL jobs pay GOOD. it's something worth learning if you want a 1%er income.

 

[Endymio]

Some extremely sketchy claims here. The eye-popping figures derive from a self-aggrandizing Cobol consulting company called "Cobol Cowboys", and a paper written by two Indian professors who themselves relied on an even sketchier mix of blog posts and magazine articles. There's no doubt that many large banks still maintain Cobol-based mainframes. But "90% of Fortune 500 companies are support by Cobol"? What does even mean? They make deposits in a bank that somewhere along the line uses Cobol?

 

[VariableSpike]

90% seems way too high, more than likely they count anything involving payment as using COBOL purely because the underlying banks use it
Weird that IBM would be pushing a switch from COBOL to Java, surely they would want something low level like some form of C to minimise transaction latency?

 

[wiyosaya]

I'm sure any entity using COBOL has been aware of the writing on the wall for years, yet has done nothing about it probably, at least in part, due to it costing them money to replace it. After all, any algorithm can be done in any other language, and from a programmer's standpoint, their COBOL is simply implementing algorithms that could be duplicated in another language.

As I see it, it is the entities using COBOL that are ultimately responsible for the dilemma of COBOL. Sooner or later, those entities will be forced to face the music, bite the bullet, etc., whether they like it or not.

 

[jbc029]

One of the largest issues with migrating COBOL is that the requirements of the systems being migrated aren't well documented or understood by the current business users. The folks who did the initial design (and requirements definition) have been gone for decades and most of that was hard copy docs.

Modules were written with the knowledge of business rules being stretched across a string of modules. SMEs were assumed to around for a while. Flowerpot comments refer to repository versions for systems migrated away from 20+ years ago. Ticket and work systems from 30+ years ago.

There's a tech paralysis now because it's not hard to find someone who can read the stuff. It *is* hard to find someone that can definitively say *why* it did it the way it was written. Was it a programmer who didn't know better or was it a concession to claw back performance because onlines need to be back by 6 AM reliably?

So much lost because we assumed the human capital would remain consistent with the software.

 

[Dr Roboto]

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.

 

[BobHome]

I'm sure any entity using COBOL has been aware of the writing on the wall for years, yet has done nothing about it probably, at least in part, due to it costing them money to replace it. After all, any algorithm can be done in any other language, and from a programmer's standpoint, their COBOL is simply implementing algorithms that could be duplicated in another language.

As I see it, it is the entities using COBOL that are ultimately responsible for the dilemma of COBOL. Sooner or later, those entities will be forced to face the music, bite the bullet, etc., whether they like it or not.

I agree. And I see it as a two-fold problem. COBOL = mainframes. To replace COBOL also means replacing Big Iron.
It would be like UPS has to not only replace their old trucks, but also the roads they drive on.
And since most of those companies running COBOL have stock, their need to feed the stockholders far outweighs the costs of upgrading. Well, until they go under. <sigh>

 

[Plutoisaplanet]

I work in a big company that used COBOL programs, and yes they can and are being replaced. We have 0 COBOL programs now and used to have hundreds, just saying. Also, developers learn new programming languages all the time, and learning COBOL is not a crazy thing. It's just that people would rather not learn a dead programming language.

 

[gamerk2]

I work in a big company that used COBOL programs, and yes they can and are being replaced. We have 0 COBOL programs now and used to have hundreds, just saying. Also, developers learn new programming languages all the time, and learning COBOL is not a crazy thing. It's just that people would rather not learn a dead programming language.

Yeah, Software Engineer speaking: COBOL isn't *that* hard to learn all things considered. The real problem is a lack of understanding *why* things were done a certain way.

 

[ferrellsl]

I graduated from college in 1987 and I learned COBOL. It was part of the curriculum for those majoring in Information Mgt Systems at the time. It wasn't/isn't hard to learn so I'm tired of hearing this gloom and doom crap about how the world is going to end because of a lack of COBOL programmers. 1987 was 37 years ago and I bet click-bait articles like this one will still be written about COBOL thirty seven more years from now in 2061. Just stop it.

 

[Antias]

I graduated from college in 1987 and I learned COBOL. It was part of the curriculum for those majoring in Information Mgt Systems at the time. It wasn't/isn't hard to learn so I'm tired of hearing this gloom and doom crap about how the world is going to end because of a lack of COBOL programmers. 1987 was 37 years ago and I bet click-bait articles like this one will still be written about COBOL thirty seven more years from now in 2061. Just stop it.

Heck, I'm the same as you... Graduated in 88, Computer and Information Systems, Business Systems Requirements and Process Analyst by profession. I was the ones writing all those hundreds of pages of System Development and Change Request Requirement Documents back then for some Aussie big banks ATM and EFTPOS divisions (was one of the very first users of Visio before it was bought out by Microsoft, although I did like their eventual integration with Office). I'm semi retired now, but I still get consulting gigs on major change projects for big bank COBOL systems (mainframes) in Australia.
I can say its extremely wierd to get a document (or 10) sent to you for background reference work that you yourself wrote over 30 years ago....

 

[mbk34]

I learnt COBOL back in 1981 when at college. It was a dead language then. It's an even more dead language now. If companies are still running COBOL programs then they most likely have no internal support of their applications or, worse, have to rely on Indian offshore teams. God help them in either case.

 

[RGRHON]

All I have to say is that before I went to work at McDonnell-Douglas in 1983 I worked with COBOL for an ambulance company to feed myself in school. The ambulance company needed to integrate their inventory, pricing, and government reporting. They also needed a search engine that worked phonetically. I wrote it all in COBOL. Once I got to work at my real job in California my earliest task was to translate Fortran 68 code that couldn't handle strings of text- it was mixed with assembly language- into Fortran 77 while I waited for my orientation. These were huge nightmare spaghetti programs, and management wanted to see what I could do. One thing the The '68 code did was to use assembly language to move long strings of text into arrays of 36 bit scientific words in common blocks. Move a variable or word in the common block and everything became misaligned. We were moving these codes to machines with more common 32 bit double words, and we wanted them to be compatible with rumored 64 bit word machines eventually, like the DEC Alpha.These '68 Fortran programs were limited to 6 character variable names. So I assure you that the highly "self documenting" and "structured" COBOL code is much easier to understand than spaghetti 68! Further, it should be pretty easy to translate COBOL into a language with a similar data structure/algorithm layout, such as C, especially with today's AI to help. Having said that, there will always be incremental coding, testing, and verification involved when converting code, even with AI, because an AI wont translate the kind of stupid code a human will write. COBOL was coded like a run-on language with few subroutines in practice at the time, so most of it would need breaking down and testing into smaller routines. So heres what management is really facing: Rewrite the code, repair it, or a hybrid of the two.. Some old fashioned code analysis (and probably ugh, flow charting) should yield the answer. Once the analysis is done, an estimate of the number of hours required must be prepared for each scenario to get the cost. Triple that, because management will cut it in half. And then comes the commitment phase. Most organizations will have to form a team of in-house and outside workers to tackle the large tasks, and somebody's got to bite off on the budget. BTW, I'll never do this again, I needed to sleep at night, so I became an aircraft SME and hardware/softrware liason! And that's the real issue, who's going to be dedicated and take on millions of lines of poorly written code when all the money is in management and all the pain is in that job?

 

[zamroni111]

Simply recruit genius programmer then send to cobol training for a month.
Good programming is more about algorithm than language

 

[zamroni111]

I learnt COBOL back in 1981 when at college. It was a dead language then. It's an even more dead language now. If companies are still running COBOL programs then they most likely have no internal support of their applications or, worse, have to rely on Indian offshore teams. God help them in either case.

Or because the money bosses don't want to spent money on better technology.
All critical applications should be made using memory safe language such as rust, java, etc.

 

[OldMainframeGuy]

Simply recruit genius programmer then send to cobol training for a month.
Good programming is more about algorithm than language

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.

 

[Ecurb]

Taught myself COBOL and IBM assembler in the late 70s while assigned to the NSA as a USAF Airman. Happy to be retired and using python when I need a bit of coding support in my home lab projects.

Not having a plan to regularly improve one’s systems has been a problem I’ve seen all my careers. It’s like buying a big house and having no budget to maintain it. It always shocked more senior management when I allocated resources to “improve the current system.” The general philosophy was that we only respond to failures and don’t “waste” resources on improvements that didn’t give us specifically requested features.

It’s often just bad short sighted management or milk the system and bail out before it gets too bad on your watch. But, hey, this is normal and why we make the big bucks!

 

[rgeer]

One of the largest issues with migrating COBOL is that the requirements of the systems being migrated aren't well documented or understood by the current business users. The folks who did the initial design (and requirements definition) have been gone for decades and most of that was hard copy docs.

Modules were written with the knowledge of business rules being stretched across a string of modules. SMEs were assumed to around for a while. Flowerpot comments refer to repository versions for systems migrated away from 20+ years ago. Ticket and work systems from 30+ years ago.

There's a tech paralysis now because it's not hard to find someone who can read the stuff. It *is* hard to find someone that can definitively say *why* it did it the way it was written. Was it a programmer who didn't know better or was it a concession to claw back performance because onlines need to be back by 6 AM reliably?

So much lost because we assumed the human capital would remain consistent with the software.

The real problem is today most "programmers" are just coders and do not know how to program. They don't have the skills to read code and understand the business and how they relate. Over my 40 years programing I've seen the new kids coming in without the skills needed to understand the business and program.

 

[USNinja]

I've been reading, hearing and even working in environments that want to migrate from COBOL for 3 decades now and I laugh at them as I do today reading this and the comments.
Saying COBOL is 65 years old is like saying the automobile is 140 years old. When you get in your car, you are driving a modern device. COBOL also gets updates, refinements and is a modern product.
With COBOL, one can develop modern applications AND execute code decades old. No other product has that kind of reliability, except maybe Fortran.

 

[hwertz]

I took a COBOL programming class in 1999, so I would be ready to do Y2K-related work on COBOL systems if necessary (it was actually sponsored by a regional bank, since they realized they had a lack of people with COBOL skills.)

The language is not that hard! It's antiquated, everything is treated as a punch card or a (database-style) record. You have a section up top a (mandatory!) comments section where one lists who wrote the software, what the name of it is and what it's supposed to do. A section where all variables are declared. And the code to get on with the work. The one weird part is that (for example) the equivalent of line numbers MUST be in columns 1-6, there's specific columns everything goes in to rather than free-flowing lines. But this doesn't take that long to get used to to be honest.

If there's really a shortage of COBOL programmers, some of these businesses with large amounts of COBOL code need to suck it up, hire competent programmers (in the general sense) then train them on COBOL. It's not a complex language, and (since it's a "COmmon Business Oriented Language") you generally have data pass in, get processed, and produce a result (usually billing data). It has a proper decimal type specifically for dealing with currency without weird rounding errors you might get using floating point math; there's no complex threading, data is generally already cleaned up and normalized.

 

[OortCloud]

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.

 

[gamerk2]

The real problem is today most "programmers" are just coders and do not know how to program. They don't have the skills to read code and understand the business and how they relate. Over my 40 years programing I've seen the new kids coming in without the skills needed to understand the business and program.

Pretty much this. The problem isn't the code per se, its understanding the underlying requirements and re-implementing with those requirements in mind. Too many would just try and reimplement the SW as written without an understanding of the underlying system.

Software Engineering is an engineering discipline, and those within it need to start treating it as such.

 

[erickmendes]

Well If you consider that japan still hanging on floppy disks and fax machines cobol would feel like an upgrade to them.

 

[Uncle Al]

Been writing in COBAL for over 3 decades, in fact started in the ARMY back in 1980. I remember attending a conference in Indy where the three inventors were lecturing. As we entered the hall they were handing out 9" fiber strands and during the lecture we were told that, as best they could calculate, this was the distance traveled in one millisecond and for those of us writing weapon related tracking software not to waste them .....