COBOL Supports the World’s Business Operations
“Fine wine gets better with age,” or so the phrase goes.
Oddly, this aphorism also in a way applies to COBOL. It was great when it was developed, but over the 60-plus years it’s been around, it’s actually improved in some ways, even enabling many companies to enter the digital age.
Reports suggesting hundreds of billions of line of COBOL code are still in use further proves its ongoing and invaluable contributions to business computing, with industries as diverse as banking, insurance, government, retail, manufacturing, healthcare and logistics extoling its virtues.
But what’s contributed to its longevity? For that answer, we’d have to start at the beginning—although some might disagree when that was. Derek Britton, global head of product marketing, AMC and IM&G Product Groups with Micro Focus, for example, pegs it as September 1959.
As he explains, “I’m measuring that from the date the name ‘COBOL’ first came into existence, which we believe was in September of 1959. If you base it on functionality, that was later in the year, around December. But then there’s the first working version of the technology, which didn’t come about until later on in 1960. The inception for me, though, is when it was given the honor of being given a name. So, we at Micro Focus look at September ’59 as the anniversary date.”
Naming and Developing COBOL
COBOL, or Common Business-Oriented Language, was just one of a few names being bandied about at that time for this new, soon-to-be-released programming language. Others included Business System (BUSY), Information System Language (INFOSYL) and Common Computer Systems Language (COCOSYL). It wasn’t until a September 1959 meeting committee members of the Conference/Committee on Data Systems Languages (CODASYL), a consortium created to guide the development of a standard universal programming language, that COBOL was decided upon, hence Britton’s anniversary marker.
“COBOL is one of the most famous acronyms in computing, but one that was left on the cutting room floor was unfortunately ‘BUSY.’ I often wondered why that wasn’t used, because when you ask COBOL programmers, ‘How’s it going?’, they all say, almost without fail, ‘Oh, I’m busy.’ So, yeah, BUSY would really have been a pretty appropriate acronym,” Britton jokingly remarks.
Names and acronyms aside, it’s actually COBOL’s initial development and functionality that have contributed to its longevity. Around that time, many people in the computing field had no idea where the technology was headed. The mainframe, for instance, hadn’t even been built then. This is in part why CODASYL—an amalgam of members of the commercial, the government and the academic sectors, as well as a few “well-chosen scientists,” Britton says—was established, to create an organized body that could help define the direction in which development languages should go.
This was quickly becoming a necessity, because the computing systems that were being put into commercial purposes were far too complicated for even some experts in the field to operate. As Britton notes, “As exciting as that new machinery might have been, it still required someone with a rocket scientist-type intellect to actually put it to use. You had to be a very, very smart person to do anything useful with it. This, right off the bat, had created a computing-skills crisis.”
What businesses and governments wanted and needed was a way of transforming these systems into something even normal people could work with. It’s been rumored that the test of computing accessibility in that era was that someone in the finance department could be taught to tell the machines what to do. “Or so the fabled story goes,” Britton adds.
COBOL: The Number Cruncher
Fable or not, this was a lofty goal—and what the CODASYL committee was asked to investigate: the possibility of building a technology that could be easily used to support business operations.
Grace Hopper has been credited with much of the foundational ideas about how that technology would need to work, already having a worked on the precursor technology FLOW-MATIC, the first English-like data processing language. As another member of the committee, Jean Sammet was instrumental in smoothing off the rough edges of the first working COBOL compiler product.
And thus the birth of COBOL, with the B in the acronym specifying the language’s original and most significant design goal: supporting business operations. “COBOL,” Britton remarks, “is pretty much peerless at what it does.”
Part of that is because it’s very data centric. Indeed, one can’t start programming a COBOL application without first defining the data that going to be part of the process flow. It has to be as detailed as possible so it isn’t misrepresented as it may be in other languages. Additionally, the underlying COBOL compiler technology integrates capabilities such as file access, file management and file sorting out of the box, eliminating the need to add separate components to handle these operations.
As important as good program construction is, the accuracy of any answers the application produces was also paramount. As Britton notes, “COBOL’s number crunching is peerless; no matter how complex the math is, COBOL can handle it, to something like 38 significant digits of accuracy in arithmetic calculations, which is far superior to many other languages. If you’re handling money, if you’re doing trades, if you’re doing payroll, if you’re sending out invoices, if you’re calculating insurance quotes, you want the math to be right. You want it to be absolutely rock-solid accurate, which is what COBOL specializes in. So, the ‘B’ in COBOL is entirely warranted, with part of its initial specifications being to handle business systems well—and data and arithmetic are key components of that.”
COBOL Is Portable and Easy to Learn
Another such specification was that COBOL be a compiled English-like computer programming language, as based on the precursor FLOW-MATIC. Thus, you wouldn’t need rocket scientists to figure out how to communicate with the new systems that were then—in and around 1959—coming online and being adopted for commercial use. Indeed, this was critical to COBOL’s initial and ongoing success, further supporting CODASYL’s B-is-for-business design objective.
“You can teach COBOL to pretty much anyone, even school children. Just ask my poor 11-year-old,” Britton says. “The spec was a Grace Hopperism, that it must use plain English and avoid symbolism as much as possible. Because of this, users can say, ‘I don’t necessarily know the business rule that it’s trying to mimic but I can certainly understand the syntax.’ This is great, because in the COBOL world, you’re more likely than not inheriting someone else’s application to look after, so you have to be able to understand what was initially written to better support the system.”
COBOL was also developed with portability in mind, meaning that, when it first emerged, it could run on any number of hardware platforms—much as it still does today. Although COBOL is most closely—and probably rightly—associated with the IBM mainframe, where it does most of its heavy lifting, it can also reside elsewhere. The 1980s and ‘90s further drove this notion of portability, when an explosion of platform choices took place. COBOL is now available on pretty much any platform one can think of, whether it’s AIX, Red Hat, Linux on IBM Z, Windows or cloud deployments.
It seems obvious that it needs to work the same wherever you run it. But in 1960, nobody knew what a de facto industry standard platform might be. Indeed, the two platforms that were used to initially test COBOL were somewhat shaky and behaved differently. So, the developers challenged themselves by making sure they could compile and run a COBOL application with the exact same results on these independent machines.
That seems like a non-issue now, but considering what the computing systems must have operated in 1960, it surely was anything but straightforward. Now, of course, we’re talking hundreds and hundreds of platforms that have benefitted from that early and somewhat predictive design element.
What’s Best for Business Computing
Even with its B-is-for-business, ease-of-use and portability attributes, some people continue to ask how COBOL has lasted so long. One easy answer would be entrenchment. According to a survey conducted by Micro Focus, 92% of respondents said that their core COBOL business systems are strategically vital to their business operations and have ongoing value, suggesting they’ve made assessments as to the benefits of the longevity of their COBOL technology.
Of course, once something has become entrenched, there’s the question about how much someone might be prepared to spend to remove or replace it. In this case, that would be COBOL applications. Some companies have indeed replaced their COBOL systems, but at cost, including for newly purchased or developed software and related support, business disruptions, training and, perhaps most crucially, lost business logic.
“If you consider where we are today as an economy, with fairly difficult times ahead, organizations have to make really smart decisions about their technology and not take too many risks. A new solution, for example, has to work, work quickly and work the first time, no excuses,” Britton says. “So, throwing away perfectly good technology and replacing it with something that might not work, no matter the costs and time involved, is taking a dogmatic view of technology rather than a business view, and you have to start with what’s good for the business.”
COBOL’s Staying Power
Much of COBOL’s success and staying power has to do with its DNA. It was well thought out and designed from the get-go, and its continued adaptability, which is enabled by both its own built-in flexibility and a robust third-party COBOL ecosystem, is also keeping the language and the systems built with it relevant.
“Overall COBOL technology is being used to modernize systems that have been around for a while, updating itself, regenerating itself, evolving and adapting to meet the needs of the digital economy,” Britton says. “So, things like cloud, Kubernetes, micro services, plus new IDEs and DevOps, taking elements of COBOL logic and reusing it in some other ways as a different service. That’s all possible with the sophisticated tooling that’s available today—COBOL is an equal player in terms of supporting tech; it’s a 2021 language.”
And people are noticing, creating COBOL-related Facebook groups, establishing organizations such as the Open Mainframe Project (OMP) COBOL Working Group, of which Britton is a chair, and attending user-group conferences and sessions such as those sponsored by SHARE and its European-affiliated GSE.
“These are all independently driven by their own members and the topic is shaped by the demand and the requests,” Britton notes. “Interestingly, COBOL is coming up again and again on the agendas as people are saying they want to continue to learn about its evolution to ensure they are making sensible future technical choices, the right investments. That’s significant and that hadn’t been happening until the last couple of years, which is very telling—and a sign that COBOL isn’t going away anytime soon.”
Much like a fine wine getting better with age.
For more information about COBOL’s 60-and-counting years of success, see also: