Skip to content

COBOL: The Language That Runs Banking

Abstract

COBOL was designed in 1959 to be readable by business managers, not elegant for computer scientists. It succeeded beyond any reasonable expectation: an often-quoted 2017 estimate has about $3 trillion in daily commerce flowing through COBOL systems, and it still runs the core systems of many banks, insurers, and government agencies. A 2022 survey commissioned by Micro Focus put the code in daily production at 775 to 850 billion lines. COBOL has been declared obsolete roughly once per decade since 1970. It is still running.

The CODASYL Committee and the DoD Ultimatum

By 1959, the US government was operating dozens of different computer systems that ran programs written in mutually incompatible languages. Moving a program from one computer to another required complete rewriting, expensive, slow, and error-prone. The push came from a Burroughs programmer in California, Mary Hawes, who in March 1959 proposed a common business language to colleagues in Philadelphia, among them Grace Hopper. A first meeting took place that month in the office of the University of Pennsylvania’s Saul Gorn; at the second, Hopper suggested approaching Charles Phillips, who ran a computer-systems research group at the Department of Defense. Phillips invited about forty people to the Pentagon on 28 and 29 May 1959, fifteen each from government and manufacturers and ten from user companies, and this became the Conference on Data Systems Languages (CODASYL), charged with designing a common business language, and once the specification existed the Department of Defense supplied the enforcement: it would not buy or lease a computer that could not run COBOL. For manufacturers, the largest customer in computing had made support non-optional. The short-range committee that did the work, chaired by Joseph Wegstein of the National Bureau of Standards, drew on six manufacturers (Burroughs, IBM, Minneapolis-Honeywell, RCA, Sperry Rand, Sylvania) and three government agencies. Grace Hopper, then head of software development at Remington Rand’s Univac division, served as a technical adviser rather than a member; her FLOW-MATIC language, which had shown that business programs could be written in English-like statements, was the strongest single influence on the result, with IBM’s COMTRAN (designed by Bob Bemer) a second source. Jean Sammet later insisted that Hopper “was not the mother, creator, or developer of COBOL.”

A six-person team of the short-range committee, including Sammet of Sylvania and Gertrude Tierney of IBM (with William Selden of IBM, Vernon Reeves of Sylvania, and Howard Bromberg and Howard Discount of RCA), delivered a draft on 7 November 1959 (that autumn RCA’s Howard Bromberg, unhappy with the pace, had a small tombstone engraved “COBOL” made and sent to Phillips). CODASYL’s executive committee approved the report in Washington on 7 and 8 January 1960, and the printed specification appeared in April 1960, eleven months from inception. The decisive test came in December 1960, when the same COBOL program ran on two different machines, an RCA 501 and a UNIVAC II. The DoD mandated COBOL for its data processing systems, and banks, insurance companies, and government agencies rapidly adopted it.

Design Philosophy: English for Business

COBOL’s syntax was deliberately verbose. A COBOL program begins with an IDENTIFICATION DIVISION identifying the program, then an ENVIRONMENT DIVISION describing the computing environment, a DATA DIVISION defining all data structures, and a PROCEDURE DIVISION containing the actual logic. A statement that adds two numbers might read:

ADD CUSTOMER-BALANCE TO TOTAL-AMOUNT GIVING FINAL-TOTAL.

This verbosity was the design intent. The committee envisioned COBOL programs being reviewed by business managers and auditors who were not programmers. The program should be understandable to anyone who could read business English. Whether this goal was achieved in practice is debatable (COBOL programs do become complex in ways that require expertise to understand) but the aspiration shaped the syntax.

Decimal arithmetic was a critical technical requirement. Financial calculations require exact decimal representation: $1.00 divided by 3 should give $0.33 with specific rounding, not the floating-point approximation 0.33333… that binary arithmetic produces. COBOL’s native decimal arithmetic, implemented without floating-point, was essential for financial applications.

Record-oriented file processing matched the data of the era: punched cards, magnetic tape, and eventually disk records. A COBOL program described the layout of records, opened files, read records, processed them, and wrote output records. This model matched how financial data actually flowed through institutional systems.

Standardization and Longevity

COBOL was standardized by the American National Standards Institute (ANSI) in 1968, and the standard has been updated in 1974, 1985, 2002, 2014, and 2023. Each revision added modern capabilities while preserving backward compatibility, a COBOL program written in 1965 should still compile under a 2023 COBOL compiler, and largely does.

The commitment to backward compatibility is the source of COBOL’s longevity. Financial institutions that wrote COBOL systems in the 1960s are still running them because the cost of replacing them (reimplementing decades of accumulated business logic, edge cases, regulatory adaptations, and institutional knowledge) exceeds the cost of maintaining them. The code works. It handles the edge cases. The programmers who understand it remember what the edge cases mean.

The Scale of the Installed Base

Estimates of COBOL’s deployment scale are staggering:

  • 775 to 850 billion lines of COBOL in daily production use, per a Vanson Bourne survey commissioned by Micro Focus and published in February 2022, three to four times the 200 to 300 billion of older estimates (Reuters had used 220 billion in 2017)
  • $3 trillion in daily commerce flowing through COBOL systems (Reuters, 2017, an order-of-magnitude estimate)
  • 95% of ATM swipes and 80% of in-person card transactions touch COBOL code (also Reuters, 2017)
  • The US Social Security Administration runs COBOL

The workforce implication is underappreciated: the programmers who wrote the core COBOL systems in the 1960s and 1970s are in their 70s, 80s, or dead. The people who maintain these systems are younger, but there are fewer of them, and each year there are fewer. Universities stopped teaching COBOL decades ago as an entry-level language; it is now specialist knowledge acquired on the job or through employer-specific training programs.

Y2K: The Most Expensive COBOL Maintenance Event

The Year 2000 problem (the use of two-digit year fields in COBOL programs that would interpret “00” as 1900 rather than 2000) was substantially a COBOL problem. COBOL programs, written when memory was expensive and every byte mattered, stored years as two digits. A loan system that calculated interest by subtracting the loan origination year from the payment year would produce catastrophically wrong results if both “origination year” and “payment year” could be ambiguous.

Gartner estimated the worldwide cost of Y2K software remediation at $300 to $600 billion, and the work was substantially the work of finding and fixing two-digit year fields in COBOL programs. The absence of major failures on January 1, 2000 was not because the problem was overstated; it was because the remediation succeeded.

Y2K was also the most comprehensive effort ever made to understand and audit existing COBOL codebases. The knowledge gained (about what systems existed, how they were structured, and what they did) has not been retained. Much of it was learned and then lost as the temporary workforce assembled for remediation dispersed.

COVID-19: COBOL Shortage Made Visible

In April 2020, New Jersey Governor Phil Murphy held a press conference announcing that the state’s unemployment system was overwhelmed by the surge in claims following COVID-19 pandemic shutdowns. He explicitly asked the public for COBOL programmers, the state’s unemployment system ran on COBOL, and the state did not have enough people who could maintain and extend it.

New Jersey was not unusual. A survey by The Verge that month found at least twelve states, among them California, Connecticut, Iowa and Kansas, still running COBOL somewhere in their unemployment systems. The pandemic revealed what had been a slow-developing crisis: these systems were understaffed, underdocumented, and difficult to extend because the expertise required to modify them was scarce and aging.

COBOL’s Future

COBOL compilers and tools continue to be maintained. IBM offers COBOL for the IBM Z mainframe, which runs the majority of enterprise COBOL workloads. Micro Focus (now OpenText) offers COBOL compilers and tools for distributed platforms. There are active efforts to run COBOL programs on cloud infrastructure.

The language itself is not dying: the 2023 standard added an optional commit-and-rollback facility (COMMIT and ROLLBACK statements), dynamic-length item handling via SET, alternate-key suppression on indexed files, and a nonfatal I/O warning condition, building on the Unicode support and object-oriented features introduced back in COBOL 2002. COBOL is being extended rather than replaced.

Myth: COBOL is a dead language.

Old is not dead. A 2022 industry survey put 775 to 850 billion lines of COBOL in active production, processing trillions of dollars in transactions daily and running the core systems of most major banks, insurers, and government agencies. COBOL has been declared obsolete roughly once per decade since 1970 and keeps running; the standard is still being revised (2023). The real risk is not the language dying but the workforce that maintains it retiring faster than it is replaced, which is the opposite of a dead language. See Myths and Misconceptions.

The workforce pipeline is the more serious concern. In April 2020, IBM and the Linux Foundation’s Open Mainframe Project responded to the unemployment-claims crunch with a COBOL talent portal, a technical forum staffed by experienced programmers, and a free training course. IBM’s announcement said its Z Academic Initiative worked with more than 120 US schools, over 45 of which had courses dedicated to COBOL. But the total number of people entering the COBOL workforce each year is small relative to the total amount of COBOL that needs to be maintained.

The most likely long-term outcome is not replacement but managed decline: as organizations migrate specific subsystems from COBOL to modern languages over decades, the total COBOL codebase shrinks gradually, the expertise required shrinks proportionally, and the transition happens incrementally rather than catastrophically. This is how legacy technology dies in financial computing, slowly, expensively, without drama.

📚 Sources