COBOL: The forgotten coding language?

Randal RedbergEE Managing Member
Thankful for the opportunity to help guide and be part of an amazing global technology community.
Edited by: Andrew Leniart
Could a sixty-year-old coding language be the next secure job market?

COBOL: The forgotten coding language?

Could a sixty-year-old coding language be the next secure job market?


When someone talks about coding languages today, you will no doubt hear the terms, Python, Ruby, Java, C++, Perl, and even some newer languages like R, GO, and Swift. When was the last time you heard someone mention COBOL? Yes, the “old school” Common Oriented-Business Language, that is COBOL. It made its debut just over 60 years ago. More than likely the term legacy technology or dinosaur will be uttered if someone mentions COBOL, but think again.

COBOL is still quietly and efficiently running financial transactions behind the scenes after all these years. Over 95% of the ATM swipes use COBOL, and $3 trillion in transactions occur over lines of COBOL code daily. Reuters estimates that 220 billion lines of COBOL code are currently in use. A large number of government and banking institutions still rely on the codebase to run daily operations and service the needs of their customers. Much of the code performing these functions were written thirty to forty years ago. 

“Two scientists were key in the development of COBOL in 1959, Mary K. Hawes and Grace Harper.”

So why are big companies still using such an old code language? Cost and time to put it simply. In 2012, according to Reuters, Commonwealth Bank of Australia took the plunge and committed to changing its core operating platform. It was no easy task, requiring the services of Accenture and working with SAP SE to make the switch. It ended up taking five years and cost the company 1 billion AUD or $749.9 million US. So why would a company move off of COBOL if it has worked so well for this many years? Much of it has to do with the lack of people who know the language, not the language itself. That being said, people are still integrating COBOL with platforms like Linux. 

The state of New Jersey is scrambling right now to find developers that can help them shore up systems that are being pushed to unprecedented limits due to the extraordinary requests being made to process unemployment claims.

Enter a new era of COBOL developers. Years back, there was a legion of coders who learned COBOL, but the problem now is that most of them have retired or passed away. Where is the next generation of coders going to come from? Cool kids don’t do COBOL, or do they? Despite the lack of interest from a younger generation, companies like IBM are investing heavily in training a new generation to be proficient in COBOL since they still sell an IBM Mainframe with the language running on it. They estimate that approximately 15,000 people are trained each year through fellowships and other training programs. Even with these efforts, younger developers are not flocking to COBOL. Part of it has to do with what COBOL is used for, generating lines of code to perform redundant tasks. No one is going to program a new app or the next social media sensation in COBOL. 

COBOL isn't going anywhere, not for a long, long time.”  Gary Patterson 

As potential new young developers come onto the scene, no doubt, a new way of thinking will come with it. Stacking and integrating other more robust languages on top of it will more than likely emerge. It also may bring out a whole new breed of developers who like to work in environments that might not have the sex appeal of becoming the next “purple unicorn,” but are happy with taking home a nice six-figure income and retiring with the same company. 

So who is to say that this very stable and reliable language won’t survive the next 60 years. Only time will tell. X

Below is an interesting Q&A with  Gary Patterson , a  Certified Expert  at Experts Exchange. 

“I see a lot of COBOL.  My company, Greymine, specializes in IBM midrange (AS/400 / iSeries / IBM i) modernization.  We also help port applications between platforms.  That means we run into a lot of COBOL and other legacy languages.”

In the case of the State of New Jersey, do you believe that COBOL itself is not able to handle the large number of requests, or was it the way the code was written originally?

I don't know the details of New Jersey's systems other than what I've read recently, but COBOL, per se, isn't really the problem in these organizations running old legacy code.  The problem is technology debt, and designed capacity.  COBOL started out as a solid, capable language, and has grown and expanded over the years.  It is a very capable tool - and programs are written in COBOL, when used and maintained properly work just fine.  But, just like an old car, they need proper maintenance.  Take your 100% original 68 Firebird 400 that hasn't been properly maintained and run it up to the redline and keep it there for a while and see what happens.  Someplace in there, some 50-year old part is going to fail.

When we work with these very old, out of date legacy systems, regardless of programming language, we generally find at least some of these common issues:

Original architects and developers long gone,

Poor original design, even based on the standards of the time.  (I've heard this referred to as "low bidder syndrome" in government software projects.)

Undocumented code,

Lost paper documentation,

Undocumented changes and fixes,

Unresolved long-term defects,

Old, outdated computer hardware, operating systems, and tools,

Inadequate change management and testing processes,

Lack of performance and load testing processes,

Lack of available skilled resources (at a price the client is willing to pay, that is).

Lack of creativity in bringing in fresh IT talent and encouraging and rewarding willingness to dive into these legacy systems, learn them, and improve them.

"If it ain't broke, don't fix it" attitudes in senior management. 

Some of the largest financial transaction processing systems, healthcare claims, telephone billing systems, utility billing systems, etc. in the world are COBOL applications running on IBM mainframe or IBM midrange hardware.  They handle daily transaction loads that I'd be willing to bet exceed what some of these state employment systems handle in a year. It has absolutely nothing to do with any limitation in the programming language itself.

System failures like this have -everything- to do with the capacity these systems were designed and (possibly) tested to deal with, and just about nothing else.  

Speed to react to these problems has more to do with poor management of these software products over time: inadequate documentation, poor design, "low bidder" procurement procedures, poor change management processes, lack of adequately skilled staff, low average pay levels for developers and contractors, limited state budgets, and "if it works, don't fix it" attitudes.

Why would someone move off of COBOL if they had access to competent developers who knew the language? I know it’s old but it obviously still works.

Platform costs, and lack of skilled developer availability, or fears about future developer shortages.  IBM mainframe is expensive to acquire and maintain compared to other platforms, and requires technical skills to operate, program, and maintain that are getting harder and harder to find.

Lack of "cool factor": COBOL is considered by many developers, especially young developers, to be "old-school" - outdated technology, and it is definitely not cool.  It is rarely taught in modern programming courses in college, so programmers have to learn on the job, or in their spare time - and many see it as a big backward step.

Finally, productivity.  It takes a lot of lines of COBOL to do what you can do in one line of C#, Javascript, Java, PHP, or other component languages that come with a large library of standard built-in tools.  Programmer productivity is better in these environments, especially for large scale development.

Could the code be written in a way to be just as robust as newer languages?

Robustness isn't about the programming language.  It is about software design, development, and maintenance practices.  I've seen really good COBOL, and terrible, impossible-to-maintain Java.  Different languages have different benefits and drawbacks, and programmers tend to be more productive in some languages than in others, but I'd take a very well-designed and coded COBOL application over a poorly done C# program to do the same function every day.

What are the limitations of COBOL and what code platform would someone likely move to if they did make a change?

Legacy COBOL is a simple, wordy, procedural language. It can be made to do just about anything, but it doesn't come packaged with a lot of components that developers take for granted in more modern languages.  So it is often complicated to do common tasks, like sending an email, or calling a web service - often taking hundreds or thousands of lines of code to perform a function that can be done in Java or C# in a few lines of code.

COBOL doesn't offer native support for multithreading, versus modern languages (and some legacy languages) that have the ability to simultaneously run multiple threads.  This makes COBOL less suitable for tasks like web application serving.  Legacy COBOL has limited support for complex data types and doesn't handle variable-length data (like XML and JSON) very well.  It doesn't directly support graphical interfaces.  

COBOL often moves to COBOL, just to a more modern flavor, programming style, and, sometimes on a different platform.  I've seen a lot of mainframe COBOL move to IBM midrange (IBM i / iSeries / AS/400), which is cheaper and easier to operate.  And there are COBOL development environments and compilers for almost every major OS, including Windows, Linux, AIX, and Unix - which include modern tools, access to libraries of common functions, GUI interface development options, and other of the productivity features found in modern programming languages and development environments.

In recent years, IBM provided guidance to COBOL users, on both mainframe and midrange hardware platforms to consider moving to Java, and provided Java environments and tools to help facilitate Java programming on IBM hardware.  Obviously, IBM wants to keep the hardware and OS sales and support revenues associated with those platforms, and offering a Java option was a good way to do it.  But you can find companies that have ported code to most popular programming languages: Java, Microsoft .NET languages, LAMP stack, etc.  These decisions are often based more on the available skillset in the organization than on some abstract "best" target language.  If the new CIO is a Microsoft fan, it is going to be .NET.  If they are an open-source advocate, maybe LAMP.

These large legacy systems are very expensive to port to another language, so another common approach is to simply buy and migrate to packaged software or migrate to a Software as a Service (SaaS) provider where suitable applications exist.

Another modernization approach is to repackage the existing COBOL programs into web services, or some other form of API, that can be used by new programs written in other languages.  The core business logic stays in COBOL, but UI, printing, and other services are developed in a more modern language that provides better support for graphical interfaces and web interfaces.

-- Gary Patterson is the VP of Technology for Greymine (, a provider of legacy software modernization and performance services.  He can be reached at

Randal RedbergEE Managing Member
Thankful for the opportunity to help guide and be part of an amazing global technology community.

Comments (2)

John TsioumprisIT Supervisor
Distinguished Expert 2020

Great Article Randal.
The whole issue with Cobol is a bit "strange" to say the least.
Just about everyone has rediscovered the "wheel" when it comes to programming but the fact is that it just boils down to money.
Let me explain it a bit.
An application no matter what consists of 3 things : the data , the logic that manipulates the data and the UI interfaces that interfaces the previous 2 to the end user.
So we have a legacy application that works, the general idea in enterprise level is "if it works don't fix it" and it would be a lie not to say that i am also in the same philosophy but.....
there is a time where we must take a look and see if we are pleased with the fact we are using some mysterious "black box" to do our job.
If the answer is YES then leave it as it is objection on that but don't come screaming some time later , that we can't find a programmer , or the workload has increased and can't handle it or whatever....the original answer was YES (remember)
If the answer is NO or even MAYBE, then its simply time for decisions and they can't be hasty, that's the fundamental fact...everything that is rushed out is doomed to fail.
I am afraid i don't know anything about COBOL (although i did make an effort to try and get some good quality source code to check it but in vain..just by doing homework level isn't going to provide much insight) but i reckon that the general idea is always the same. (well i did came across an ancient Cobol based ERP -no source code , lost....-  that i made some kind of a bridge that uploaded the data (.dbfs) to the cloud (MySQL) but the owner just couldn't cope with the whole concept and decided to stick with it as it was .... i see some messages from him from time to time about future problems his application will face but that's a forgotten story)
Let me share a story of the past.
Many many  years ago when i was a new IT guy (not programmer yet) i was hired by a company to do hardware/software maintenance.
As time was passing i was forced to learn programming in order to maintain my paycheck  - no problem on that minus the fact i received almost no help and there was quite some nagging -  and after some time (and some more tales) i was in the following position.
A new programmer was hired,- an exceptional great programmer by any means - at that time  was doing basic applications supporting the company's application but i had never touched the "core".
This new guy just grabbed his chair and was just reading the code (we had a massive application in Access measuring over 200K lines of code)...and he was just reading, reading and keeping some tiny tiny notes using a pencil on some little pieces of papers.
Thankfully the administration was very "flexible" in the concept that didn't required the new programmer to take over and gave him quite some time without nagging....for the first months ... :)  
At some point he started producing and suddenly in a matter of months the application did received some pretty good enhancements....everyone was happy.
But money is always the problem and the guy just grabbed the opportunity and one day just flew ...
So what...the whole system was adjusted around what.
This was the time i had to take over, i simply followed his example, instead of creating extra applications that were revolved around the core application i just dived into the core of the application.
It took me quite some time to get the hang of it as the code was quite twisted...a bit of naive but i used Excel to write down all the important steps (now i laugh at my self as they are a lot of tools that could do much better work but probably administration wouldn't pay for them but is another story)
So i wrote down everything i could understand...and in a few months this just paid off (not in money :) ) ...I suddenly understood the complete system so i knew in case of a problem or a feature request what to look and how to fix it or make it.
Simply as that, my programming took off as i became more productive (in meaningful level) and this continued till i left...
The administration did came some day and asked me to migrate it to another platform (.NET+SQL) ...alright no problem on that i can do it...but i need time, its a hefty application and i am a single developer (almost) so estimated it would take a whole year...No, i want it likewhat in a few days ,like migrating the data over the weekend and just continue as usual, i declined, i quoted my detailed planning with all the steps, again there was a denial, so we left it as it was....few years later i left the company...till today i know that the system remains the same and is getting worse day by day...but it was their decision.
In between i came across another similar case, a devious twisted Java Machine Learning application , it was my thesis to improve it, a 15 years old project that was sitting in the drawers for someone to undertake and bring it to the next level. (drawbacks : i have extremely low knowledge of Java, just 1 semester and then when i finally undertook the project my teacher informed me that he is no longer programming and he couldn't help me).
Again the same procedure, writing just everything i i used some tools but the basic was notes/mind maps and of course Excel.... :)  ( i just couldn't get rid of it)
So i ended rewriting some part of the application bringing mainly the UI to the JavaFX platform and that's was all.
So to my mind there isn't such a thing like a legacy application that we just can't migrate, is just a matter of taking the decision.
And yes it's on you if you have left your business going on a legacy application and you don't make the decision to hire the right people to do the necessary things :
- Understand the code how it works
- Make the decision which platform suits us better for the future
- start chopping the initial code to smaller parts in order to migrate the logic to the newer platform
- prepare the new interface
- migrate the data to a more robust database engine (if needed)
- start rewriting - migrating the code to the new platform
- wire the new interface to the new code
- testing and retesting the new code to ensure that everything works as it should (this should be the most frustrating part but when you have working code that you can actually see how it works, just  pull all the past data and let it run on all of them...if it pass then any failure probably would either even the legacy code would fail or we are talking "winning the lottery" cases)
- replacing the legacy application to the new platform
It will cost quite some money (time is also money so it goes back to money) but in the end you could say, i have liberated from an ancient system and now i don't have to make the headlines about seeking programmers that are not there...
The decision is just what is holding you off.
Chris Harte2015 Top Expert (Most Article Points)

“Two scientists were key in the development of COBOL in 1959, Mary K. Hawes and Grace Harper.” ?

Or Grace Hopper as history remembers her.

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.