The Last Engineers: A Record of Vanishing IT Traditions (3)

Episode 3: COBOL

Those Who Kept the Lifeblood of Society Flowing

This article is a documentary-style creative column that begins with a reader's question. While not based on an actual program interview, it is structured to reflect the atmosphere that once existed in Japanese technical workplaces and to pose questions for the current AI era.

In the first episode, we spoke with Mamoru Kodai about fuzzy logic control.

An era when machines tried to understand the "vague" nature of humans.
There, we found engineers who did not mock human ambiguity.

In the second episode, we spoke with Shiro Sanada about assembly language.

Registers, addresses, interrupts, clocks.
It was a story of an era when humans took on the machine's burdens right alongside machine code.

In the third episode, we visit COBOL.

An old language that still quietly continues to run in the depths of finance and government.
A language called old, yet never permitted to stop.
A language that is not new, yet one that no one can easily discard.

COBOL.

It was a language written to ensure the lifeblood of society never stopped flowing.

The question sent in by a reader this time was as follows:

"Is COBOL still in active use? I hear it's an old language, so why is it still used in banks and government agencies? Can't it be replaced by AI?"

To trace the answer to this question, we visited a former bank employee.

In the suburbs of the metropolitan area.
In a corner of a residential neighborhood where old housing complexes and new condominiums stand side by side, lives a man who, after working at a regional bank branch, was involved in the development and maintenance of core banking systems at the head office's computer department.

Juzo Okita, eighty years old.

When he was young, he experienced teller work, cash handling, collections, and loan administration at a branch.
After that, he transferred to the head office's computer department and was involved in the maintenance of ATM integration, night batch processing, loan management, report processing, and settlement processing.

On his study desk, there were not only old COBOL specifications.
There were also an abacus, paper bands for bundling banknotes, old bankbooks, copies of yellowed loan approval documents, and magnetic tape cases.

Mr. Okita tapped the abacus with his finger and smiled quietly.

"When I joined the bank, it was the abacus before the computer. Being able to write bank numerals with a ballpoint pen. Being able to count banknotes accurately. Being able to go around collecting money on a bicycle or a 50cc Super Cub. That was the foundation of being a bank employee."

Bank figures.
Counting banknotes.
Vouchers.
Passbooks.
Personal seals.
Approval documents.
Collateral ledgers.
Collection bags.

To young people today, these might look like outdated business practices.

However, each one was a physical skill that once supported the banking industry.

Flicking through banknotes with a thumb.
Balancing totals with an abacus.
Reading voucher numbers without error.
Writing amounts in bank numerals to prevent tampering.
Going out for collections even on rainy days.
Remembering customers' faces.
Reading the branch manager's mood.
Sensing the atmosphere of the head office's credit department.

That was the work of a bank clerk.

Okita picked up an old passbook.

"Bank clerks in the old days, they seemed to be dealing with numbers, but they were dealing with people. Behind every passbook, there were shops, factories, and families. Even a single line of balance had a life behind it."

There was a language that gradually transferred that bank clerk's work into machines.

It was COBOL.

COBOL was born in an era when computers were still special machines.

Companies and government agencies were burdened with massive amounts of administrative processing.

Calculating payroll.
Processing invoices.
Managing inventory.
Updating bank account balances.
Managing insurance contracts.
Calculating taxes.

These are not difficult mathematical problems.
However, they were processes where mistakes were not allowed.

If it didn't balance by even one yen, you couldn't go home.
If a digit was off, society would be shaken.
If one record disappeared, a person's life would change.

Okita opened a thick specification document.

In it, the specifications for deposit balances, interest calculations, loan balances, repayment schedules, collateral valuations, delinquency classifications, transaction histories, and report outputs were written in detail.

"COBOL isn't a language that erased bank clerks. It's a language that moved what bank clerks were doing into machines. Accounts that were balanced with an abacus are now balanced in night batches. Ledgers that were flipped through by hand are now read as files. Balances that were checked at the counter are now displayed on terminals. We taught the machines to do those things, one by one."

COBOL is not a flashy language.

It doesn't move pictures on a screen.
It doesn't fly spaceships.
It doesn't converse like a human.

MOVE.
ADD.
PERFORM.
IF.
READ.
WRITE.

The instructions are plain.

Yet, that plainness was their strength.

Handle amounts correctly.
Maintain digits accurately.
Produce reports correctly.
Keep records accurately.
Ensure everything can be explained during an audit.

COBOL moved money and records behind the scenes of society.

"It may look plain. But it is good because it is plain. You don't need clever magic for processing money. Being readable. Being traceable. Being explainable. That is what matters."

Eventually, the landscape of banking changed.

ATMs appeared.

You could withdraw cash without waiting in line at the counter.
Insert your passbook, and your balance would be printed.
Insert your card, and the machine would verify your identity.
You could conduct transactions at night or on holidays.

It is something we take for granted now.

However, for Okita-san's generation, it was an event that changed the lives of bank employees.

"When the ATMs arrived, it felt like the administrative work that used to be in the back of the bank was being sucked into the machines. The verification, bookkeeping, and balance inquiries that humans used to do behind the counter started running inside terminals and host computers."

From the user's perspective, the ATM screen is just a small portal.

But behind it, there was the core banking system.
There were branch terminals.
There was night-time batch processing.
There were balance files.
There were transaction histories.
There was error handling.

COBOL was running behind all of that.

"ATMs were convenient. But the more convenient they became, the stricter the balancing behind the scenes had to be. Things that humans used to stop at the counter were now being processed by machines. As a result, the number of places where the machine absolutely could not make a mistake increased."

From there, the conversation drifted a little off-topic.

Even though we were supposed to be talking about COBOL, before I knew it, Okita-san had started talking about loans during the bubble era.

"During the bubble, the banks and the world were a little intoxicated."

Okita-san tapped a yellowed copy of a loan approval document with his finger.

"Credit seemed to have flown away somewhere. All they looked at was collateral. Land. The assumption that it would rise in value in the future. Even a mountain forest worth 10,000 yen per tsubo would become 100 million yen per tsubo in a loan document if it had a map, a fax, and a plausible business plan attached. Once numbers are entered into a report, people suddenly want to believe them."

Land prices will never fall.
It's fine because there is collateral.
It's fine because it will rise in the future.
Capital gains are enough to cover the repayment.
If we don't lend now, another bank will take the deal.

That was the atmosphere during the bubble era.

Okita-san gave a slight, bitter smile.

"The land myth was a religion. Land prices will never fall. It's fine because there is collateral. It's fine because it will rise in the future. Everyone dreamed the same dream. While you're dreaming, no one calls it a dream. They call it a rational premise."

It was COBOL that processed those numbers night after night.

Loan balances.
Repayment schedules.
Collateral valuation.
Delinquency management.
Loan loss provisions.
Non-performing loans.

The myths created by humans eventually became reports.
The myths that became reports were processed every month within the system.

"The land myth was created by humans. But it was the system that processed those numbers every month. Humans got drunk, and the machines balanced the books. That was the kind of era it was."

Humans get drunk, and machines balance the books.

That statement was close to the essence of COBOL.

COBOL does not dream.

It doesn't say land will rise.
It doesn't say collateral is safe.
It doesn't say a loan is right or wrong.

It simply processes the numbers that are input.
It updates balances, calculates interest, generates repayment schedules, records delinquencies, and spits out reports.

At that point, Okita-san suddenly began talking about modern times.

"I smell something similar lately."

When I asked what he meant, Okita-san cleared his throat theatrically.

"No, I won't name names. But when I hear someone like Masayoshi Sondan of Sodom Bank talking about AI, ASI, omniscience, and human wisdom increasing ten-thousand-fold, it makes my generation's noses itch a little."

Okita-san reached for his teacup.

"It was the same during the land myth. It's fine because there's land. It's fine because there's collateral. It's fine because it will rise in the future. This time, it's 'it's fine because there's AI.' It's fine because there's computing power. It's fine because there are data centers. It's fine because everything will be smart in the future. The words have changed, but the smell is similar."

It seems we have come a long way from the topic of COBOL.

However, for Mr. Okita, it was the same story.

The land myth and the AI myth are both devices that convert future value into current credit.

A future that has not yet been realized.
Revenue that has not yet been generated.
Productivity that has not yet been proven.
A market that does not yet exist.

These are used to explain current investments, loans, stock prices, and corporate bonds.

Like an old banker, Mr. Okita sensed the same scent in it.

"If you say the future is bright, current debt looks lighter. This has been the same since long ago. Land, AI, space, the metaverse—the name doesn't matter. When people borrow money using the future as collateral, they almost always have the same look on their faces."

Those words held not just the cynicism of an old man, but the realization of someone who has seen the books balanced.

The terror of a bubble is not that there are no numbers.

Rather, it is that there are too many numbers.

There are tables.
There are graphs.
There are assumptions.
There are scenarios.
There is future value.
There is collateral valuation.
There is a growth rate.

Yet, no one ever checks until the end whether those assumptions are connected to reality.

"The terror of a bubble, you see, is not that there are no numbers. It's that there are too many numbers. There are tables. There are graphs. There are assumptions. There are scenarios. But no one ever checks until the end whether those assumptions are connected to reality. Such times are dangerous."

In the era of the land myth, people assumed rising land prices.
In the era of the AI myth, people assume rising computing power and intelligence.

Both are mechanisms that convert future value into current credit.

The difference is that the collateral has changed from land to intelligence.

"In the old days, land was the collateral. Now, future intelligence is the collateral. But you see, collateral is meaningless if it cannot be liquidated when the time comes. Will an omniscient and omnipotent AI really pay back the debt? When you ask that, the conversation suddenly becomes abstract."

Mr. Okita laughed at that point.

It was not so much sarcasm as the laugh of an old man seeing a scene he had witnessed before.

"After the land myth, bad debts remained. What will remain after the AI myth is still unknown. But one thing I can say: the ones who balance the books in the end are never the ones who told the myths. It is the ones who can read the ledgers."

COBOL does not tell myths.

I won't say AI will save the world.
I won't say land prices will rise forever.
I won't say human wisdom will multiply.
I won't say we will suddenly turn a profit next term.

I will, however, keep the numbers.

Balances.
Repayment schedules.
Interest.
Arrears.
Allowances.
Valuation losses.
Processing dates.
Exception categories.
Report numbers.

Humans create myths.
COBOL processes the numbers after those myths have broken.

"Humans create myths. Machines process the numbers after those myths have broken. COBOL has been doing that kind of dirty work all along."

Eventually, the times changed even further.

Open systems.
Client-server.
Windows.
The Internet.
Web systems.
Cloud.
Smartphones.
Generative AI.

New terms appeared one after another.

COBOL began to be called old.

Black screens.
Old terminals.
Thick specification documents.
Long variable names.
Massive amounts of reports.
Mysterious batch processing.
Retired staff.

These things began to be spoken of as symbols of old systems.

However, COBOL did not disappear easily.

Why is that?

Mr. Okita said quietly,

"It doesn't remain because it's old. It remains because it's still running."

Old is bad.
New is good.

It cannot be divided so simply.

Old systems have reasons for being old.
The fact that they have been used for a long time also means they have endured reality for a long time.

System changes.
Tax reforms.
Financial restructuring.
Branch consolidations.
Product additions.
Exception handling.
Historical data.
Old contracts.
Audit compliance.

Decades of changes have piled up within the code.

It may not be a beautiful design.
However, it is the very history of reality.

"This thickness, you see, is not the thickness of waste. It is the thickness of social convenience. Systems change. Companies merge. Exceptions increase. We add new products while keeping old contracts. It becomes this thick by carrying all of that."

The terror of COBOL systems lies in the fact that you cannot understand them just by looking at the code.

Within it, there is business.
There are regulations.
There are exceptions.
There are past promises.
There are audits.
There are the lives of the users.

If it were just a matter of rewriting the program, it might be possible.
However, transferring the entire memory of a society is not simple.

"If it were just changing COBOL to another language, young people might be able to do it. AI might even be able to perform a plausible conversion. But why does that process exist? Why does that exception remain? Why is that one line treating old contract holders differently? If you replace it without understanding that, it will inevitably lead to an accident."

The history of the workplace is embedded in COBOL programs.

Processing is different for only one branch.
Tax rates are different for only one fiscal year.
Calculation methods are different for only one contract.
Output forms are different for only one customer segment.
Collateral valuation is special for only one loan.

It may not be beautiful as a design.
But reality is not beautiful.

This is because social systems do not exist for the sake of clean data models.

"Young people ask why such messy processing remains. I understand how they feel. But that messiness is the trace of having accepted reality. If society could run on clean code alone, no one would have any trouble."

Currently, we are witnessing code generation by AI.

AI can explain COBOL code.
It can convert it to other languages.
It can add comments.
It can also suggest test cases.

That has the potential to be useful.

However, Mr. Okita is cautious.

"AI might be able to read what is written. But it cannot read the reasons that are not written. Why did the specifications become that way? Who was troubled by what, and why did they add that process? Which regulatory change caused which part to be touched? If you just convert it without knowing those things, you cannot be at ease."

Code does not tell the whole story.

Especially in the world of COBOL, business knowledge outside the code is crucial.

Rounding of amounts.
Closing dates.
Payment dates.
Holiday processing.
How to retain old systems.
Audit trails.
The order of forms.
Items that do not appear on the screen but are monitored by the staff on-site.

These are not merely technical specifications.

It is the very operation of society itself.

"The fact that AI makes mistakes is not the problem itself. Humans make mistakes too. The problem is that we don't know how it makes those mistakes. Why did it make that judgment? Based on what premise did it perform that conversion? If we cannot see that, we cannot put it into a core system."

Sanada-san, the assembler expert, spoke of the terror of a single machine clock cycle.

Okita-san speaks of the terror of a single social transaction.

A single salary payment.
A single pension payment.
A single insurance contract.
A single bank transfer.
A single tax amount.
A single account balance.
A single loan.
A single collateral valuation.

These are not merely data.
They are someone's livelihood.

"If an account is off by one yen, for an engineer, it doesn't end at one yen. It means something was done wrong somewhere. You must not stop until you have tracked that down."

If there is a bug, you can just fix it later.

Modern software culture has that kind of sensibility.
Apps are updated.
Cloud services are updated.
Browsers are updated.
AI models are updated.

However, in the domains that COBOL has supported, there is a limit to the phrase 'fix it later'.

After a salary is paid incorrectly.
After pension records are corrupted.
After balances are mismatched.
After tax amounts are miscalculated.
After insurance payments are halted.
After loan balances are processed incorrectly.

That 'after' directly touches people's lives.

Okita-san said it clearly.

"There are places where the phrase 'I'll fix it later' is acceptable, and places where it is not. Salaries, pensions, balances, insurance, taxes, loans. You cannot say that these things can just be fixed after a mistake is made. The moment a mistake is made, it is already shaking someone's life."

COBOL was not disliked because it became old.

It was taken lightly because it became invisible.

Behind the screen.
Deep within the reports.
Inside the batch processing.
Deep inside the mainframe.
Beyond the logs that no one looks at.

COBOL remained there.

It is not flashy.
It is not glamorous.
But it kept running through the night so that society could greet the morning.

Okita-san picked up an old magnetic tape case.

"Back in the day, we'd run jobs at night and check the results in the morning. If it crashed, we'd trace the cause from there. There were sleepless nights. But when morning came, the banks would open. Government offices would open. Companies would start moving. We couldn't afford to stop it."

We couldn't afford to stop it.

In those words lies the essence of the COBOL workplace.

Assembler was a language for listening to the heartbeat of the machine.
COBOL was a language for keeping the pulse of society from stopping.

In the age of AI, we are captivated by novelty.

Speeding up.
Automation.
Generation.
Optimization.
Replacement.
Modernization.

All of these are necessary.

However, the word 'modernization' sometimes hides a certain danger.

What are we discarding?
What are we migrating?
What are we keeping?
Which exceptions are we protecting?
Whose lives are we touching?
Who will take responsibility for balancing the books of which myths?

You cannot erase the old without knowing those things.

Mr. Okita said this at the end:

"I'm not saying we should protect old systems. They must be changed eventually. But if you are going to change them, you must know what you are inheriting. It is fine to discard COBOL. But you must not discard what COBOL has been carrying on its back."

Outside the study window, the evening light was slowly fading.

On the desk, old specification documents were piled up.
That stack of paper looks like the wreckage of old technology.
However, if you look closely, it was also a trace of how society has recorded itself.

Customer number.
Payment date.
Contract classification.
Tax rate.
Deduction amount.
Balance.
Loan balance.
Collateral valuation.
History.
Exception handling.

Each one is plain and simple.

But those plain, simple lines were connected to people's lives.

COBOL.

It is not a language of the past.

It was a language for keeping the present from stopping, while carrying the past on its back.

And the fact that fewer people can read that language is not merely a problem of technical succession.

It is a question of who will decipher the memories of society.

Finally, Juzo Okita closed the thick specification document and said.

"First, let me see the forms. That is where what that era believed in, what it got wrong, and what it hid remains."

Episode 3, COBOL.

It is the story of a language written in the depths of finance and administration to keep the lifeblood of society flowing.

COBOL is not an old language.

It is the language of an era when society entrusted its memories to machines.

Next time, TRON.

We will visit the story of a domestic OS that dreamed of a future where everything is connected, long before smartphones.

Text by Rintaro Takechi