Software Development

COBOL and the Economics of a “Dead” Language That Still Moves Trillions

Every few years someone declares COBOL dead. Yet banks, insurers and governments keep running it. Unlike a language in decline, COBOL is a story about persistence, and the reasons are mostly economic, not sentimental. Along the way, we will also separate the solid facts from the statistics everyone repeats without checking.

How a 1959 Committee Built Something Permanent

COBOL was designed in 1959 by CODASYL, and Wikipedia’s overview notes it was partly based on Grace Hopper’s FLOW-MATIC. It grew out of a U.S. Department of Defense effort to create one portable language for data processing. First, that goal of portability mattered. Later, formal standards followed, and the current one is ISO/IEC 1989:2023.

Consequently, COBOL did not fade like most languages of its era. It simply kept accumulating programs that nobody could afford to throw away.

The Famous Numbers, and How Far to Trust Them

Most COBOL articles quote the same handful of figures. They trace back to a Reuters report from April 2017 (this link is a reprint), whose graphic cited Celent, Accenture, IBM, Micro Focus and others. Reuters described the $3 trillion daily figure as an estimate. In my searches, I could not find a published method behind these numbers, and almost every later article repeats them second hand.

ClaimQuoted figureHow to treat it
ATM swipes using COBOL95%Widely repeated 2017 estimate, method unpublished
In-person transactions80%Same source, same caveat
U.S. banking systems built on COBOL43%Same source; a U.S. figure often misquoted as global
Lines of COBOL in use220 billionEstimate; nearly a decade old
Daily commerce through COBOL$3 trillionReuters called it an estimate
Reuters (April 2017), as repeated by many outlets. These are unverified estimates, so read them as “very large”, not as precise measurements.

Even so, firmer evidence points the same way. A 2018 inspector general report found the Social Security Administration maintained more than 60 million lines of COBOL, as CNN reported. So the direction is clear, even if the exact percentages are not.

The Technical Reason: Exact Decimal Money

Next comes the part rarely explained. COBOL describes data in the data division, with picture clauses such as PIC 9(9)V99: nine digits, an implied decimal point, and two decimals. Money is therefore stored as exact decimal, not as a binary approximation. Floating point, by contrast, cannot represent 0.10 exactly.

The demo below adds ten cents one million times, once in a decimal field and once in a double-precision float. It uses GnuCOBOL, a free compiler. I ran this exact block with GnuCOBOL 3.1.2 on Ubuntu.

# Debian/Ubuntu: sudo apt install gnucobol   (macOS: brew install gnucobol)
cat > pennies.cob <<'EOF'
IDENTIFICATION DIVISION.
PROGRAM-ID. PENNIES.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 DEC-TOTAL  PIC 9(9)V99 VALUE 0.
01 FLT-TOTAL  COMP-2 VALUE 0.
01 FLT-SHOW   PIC 9(9).9(9).
01 I          PIC 9(7).
PROCEDURE DIVISION.
    PERFORM VARYING I FROM 1 BY 1 UNTIL I > 1000000
        ADD 0.10 TO DEC-TOTAL
        ADD 0.10 TO FLT-TOTAL
    END-PERFORM
    DISPLAY "Decimal: " DEC-TOTAL
    MOVE FLT-TOTAL TO FLT-SHOW
    DISPLAY "Float  : " FLT-SHOW
    STOP RUN.
EOF

cobc -x -free pennies.cob -o pennies
./pennies

On my machine, the decimal total was exactly 100000.00. The float total came out as 99999.999996130. You may see a harmless compiler warning, and the last float digits can differ between versions.

To see how the float error grows, I also summed 0.1 repeatedly in Python’s IEEE 754 doubles and compared each result with the exact value:

Python 3 float64 sums of 0.1 versus exact decimal. The decimal error is exactly zero, so it cannot appear on a log axis.

Admittedly, the drift is tiny: roughly 0.00016 after ten million additions. However, auditors need books that balance to the cent, with documented rounding rules. Modern languages solve this too, for example with decimal types or integer minor units. COBOL simply made it the default from the start.

The Economics: Why Rewrites Keep Losing

Meanwhile, the real barrier is cost and risk. The code works, it encodes decades of business rules, and a failed replacement can stop payments. Three documented episodes show the scale.

EpisodeWhat happenedSource
Commonwealth Bank of AustraliaReplacing its core COBOL platform took five years and cost $749.9 million (2012 start)BMC blog quoting Reuters
Social Security AdministrationMore than 60 million lines of COBOL in 2018CNN citing the inspector general
New Jersey, April 2020362,000 unemployment claims in two weeks hit 40-year-old mainframesThe Register

In other words, replacing the system costs hundreds of millions up front, while keeping it costs a steady stream of maintenance. Because the rewrite carries the risk, many organizations rationally choose to wrap the old core with APIs and leave the logic alone. By contrast, the savings from a rewrite are speculative.

What New Jersey Actually Taught Us

The 2020 appeal for COBOL volunteers became a meme. Nevertheless, the details are more nuanced. According to a COBOL consultant quoted in Communications of the ACM, the claims problem was not a back-end failure, because every claim sent to the mainframe was processed. So the headline blamed the language, whereas the evidence points to surrounding systems and a shortage of people who understand them.

That shortage is the genuine risk. Skills and documentation, rather than the language itself, are what age badly.

Checklist: before proposing a COBOL rewrite

  • You can name the business rules the code encodes, and who verifies them.
  • You have priced the rewrite against years of running costs, not just this year’s.
  • A parallel run can prove the new system matches the old one to the cent.
  • Wrapping the core with an API has been ruled out for a stated reason.

What We Learned

COBOL survives because it solved a business problem early, stored money as exact decimals, and then accumulated decades of trusted logic that is costly and risky to replace. The famous statistics, such as 95% of ATM swipes and $3 trillion a day, come from a single 2017 Reuters estimate and deserve caution. The firmer evidence, from the Social Security Administration’s 60 million lines to a rewrite that cost nearly $750 million, still shows enormous inertia. The practical lesson for engineers is to question the cause of a failure, as New Jersey showed, and to plan for people and documentation, not just code.

Eleftheria Drosopoulou

Eleftheria is an Experienced Business Analyst with a robust background in the computer software industry. Proficient in Computer Software Training, Digital Marketing, HTML Scripting, and Microsoft Office, they bring a wealth of technical skills to the table. Additionally, she has a love for writing articles on various tech subjects, showcasing a talent for translating complex concepts into accessible content.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Oldest
Newest Most Voted
Back to top button