
Cobol Still Powers the Global Economy - psim1
https://www.tpr.org/post/how-cobol-still-powers-global-economy-60-years-old
======
hermitdev
One of my last jobs as an intern in 2004 was to rewrite an old batch process
COBOL app in C# and ASP.Net. App was basically input about 6 fields, and based
up some rules. It really wasn't terribly complicated, but I had to read the
source to understand exactly what it did. It was also my real exposure to
COBOL. Took me a while to realize that around 60 printed pages of the 80ish
page program was nothing but hard coded data tables and rules, when this, then
that, etc. Once I realized that, it was a few simple regexs to pull that and
transform to xml (was early 2000s...).

While decyphering the remaining logic, I discovered what I think is the most
evil programming construct I've so far seen; think goto is bad? Meet MOVE NEXT
SENTENCE. COBOL is traditionally written in all uppercase (and historically
EBCIDIC). So what does "MOVE NEXT SENTENCE" do? It's an unconditional jump to
the next period, that's right '.'. Thats right, in a language where everything
looks like it's yelling at you, you have to find a little tiny period to find
where execution resumes. No labels, just a tiny couple of pixel round period.
Fun...

~~~
tjalfi
COBOL has a worse construct than this.

ALTER LABEL1 TO PROCEED TO LABEL2

This will cause any gotos to LABEL1 to be redirected to LABEL2.

This is worse than older Fortran's arithmetic IF[0].

[0]
[https://en.wikipedia.org/wiki/Arithmetic_IF](https://en.wikipedia.org/wiki/Arithmetic_IF)

~~~
euske
You can do that (or worse) in C too.

#define LABEL1 LABEL2

Is there any language that can be worse than a macro and #ifdef-ridden C? I'm
only half joking.

~~~
Faark
Your C #define is done at compile time. This Cobol's alter example [1] seem to
do so at runtime. Thus labels can be considered modifiable points. Actually,
it's kinda interesting... does it support chains? Alter A->B and B->C, does
GoTo A call C? If i now alter X->A then A->D and GoTo X, where do you end up?
C? D? Hope you can at least undo that with something like alter A->A.
Actually, I probably don't even want to know. Hope using it gives a big
warning in whatever tools Cobal devs use.

[1] [https://riptutorial.com/cobol/example/19820/a-contrived-
exam...](https://riptutorial.com/cobol/example/19820/a-contrived-example-
using-alter)

------
aksss
I worked on Y2K remediation fixing COBOL programs I'd never seen before at a
large oil company. It's an easy-to-understand language by design. The
complexity of dealing with the apps/jobs wasn't the code or the impact
analysis, but just the volume of work -- the endless test cases. The nice
thing about those systems was that because they were financial apps, success
was pretty black or white. Either things balanced and agreed with production
or didn't. But sooo many green bar reports. Killed many green bar trees in
'98\. My theory is that if you like programming, preferences aside, you'll
appreciate the beauty in any language, COBOL's no exception once you grok it.
May not be sexy but I've seen sexier languages come and go in 20+ years.

------
dlivingston
> “I think there is a misconception about [COBOL]. A misunderstanding about it
> as far as it being old. Usually in technology we think because it is old it
> is irrelevant,” he said. “But it’s still the fastest processing language out
> there.”

I thought this comment was born from naivety or bias, but after reading up on
it a little further, it appears that it's true or close to true for many
cases.

~~~
tapland
I think it mostly stems from IBM compiler optimizations for their mainframes
(which is most of today's COBOL), and not the language itself.

I do COBOL mostly in OpenVMS and only tinker with IBM in the weekends but it
would be cool to see how it performs under the same circumstances compared to
other languages.

~~~
kragen
You surely know more about COBOL than I do, but what about decimal arithmetic?
I mean if the problem domain requires arithmetic correctly rounded to
thousandths, with the operands loaded from fixed text fields and the results
stored in fixed text fields, COBOL gives you that directly in the language,
and presumably on a relatively efficient form. I don't know if using
instructions like 8086 DAA and AAA is a win on today's CPUs, but surely
avoiding the sequence of long divisions to convert from binary to decimal is a
win (if what you're doing between input and output is, like, an addition and a
multiplication by 1.0575, or something). Are you thinking that maybe some C++
template Decimal class with some integer parameters is going to beat GnuCOBOL
on an amd64?

~~~
tapland
I wish I could give you a good answer, but I really haven't dug deep into the
pros of the language. If you see any review of this I'd love to read it as
well.

------
orpheline
My first gig out of college was maintaining Cobol at a bank for two years.
Some of the programs were 20+ years old, and we made changes monthly - it
always seemed like a fantastic rate of churn.

If something went wrong during a deployment, heaven help you. One time a pair
of transposed digits got through testing and code reviews and into deployment.
My colleague spotted it and called the management center to hold jobs...
Thirty seconds too late.

It took four days to back everything out.

~~~
throwawayForMe2
Standard procedure was to have a pre-batch and post-batch backup step. Any
major problems you restore everything to the pre-batch state.

~~~
orpheline
That's basically what we did. The problem here was that processing was split
into eight or so steps across ~25 streams of work between the backup steps and
was far enough along the output files were generated, revving their generation
number. Those files fed something like thirty follow-on jobs, so all the file
generations had to be backed out before processing could run.

It all seemed horribly complicated and brittle to me at the time. Not sorry I
don't work with it any more.

------
aetherspawn
At my last job they had a custom variant of COBOL and hey I don’t know why
everyone is playing it down. It was beautiful. You could make a full GUI form
with full validations in like only a few lines of code.

Like a whole tax form is how you’d do a Hello world.

And then we ported the runtime to render web pages over a web socket and
that’s when things got really interesting. 20+ MLOC of legacy apps rendering
directly to the web.

It’s such a flexible language and I absolutely enjoyed working on the run time
and the other guys in the company really enjoyed writing in it.

------
segmondy
Cobol is mostly likely around because no one knows exactly what the code does.
Missing design documents & decisions don't help either. Companies making money
are risk adverse, they won't risk killing their golden goose over a rewrite,
it's often companies that are not making money that go on massive rewrites
believing that new tech will give them the Midas touch towards profit.

~~~
0x445442
I had a contract about 10 years ago for a major city's water department. The
contract was to convert an internal application for customer billing, written
in COBOL running on the mainframe to a web application backed by Oracle.

When I started gathering requirements from the city's rep who was my point of
contact I asked them for any documentation they had such as use cases,
functional specs etc. All they could provide was the original COBOL source
code bound up in those huge 17"x14" binders; the one's that have the holes
along each side from the old dot matrix printers with every other line having
that faint light green background.

Well I'd never seen COBOL in my entire live and I could only look at the code
for about an hour before my eyes started to bleed. Fortunately I was able to
get restricted access to the system and it ended up being pretty easy to just
reverse engineer the thing by mapping each green screen of the app to a
corresponding web page. In the end I didn't need any original code or
documentation to do the job.

~~~
KC8ZKF
Is your code still running? Did it suffer significant downtime? Did anything
else break because of the new code? Did anyone do without water?

~~~
0x445442
Yes, no, no and no... AFAIK :)

------
codr7
I once had a boss who was an old Cobol Cowboy, he walked me through a
financial system that's still in use.

I can't help but feel that even back in the days, they would have been better
served by Pascal with fix point math. The only convenient features I could
spot were related to working with records in files, and Pascal has that
covered.

Their Cobol implementation sort of, kind of supported subroutines but they
were such a pain in the ass that code was usually copy-pasted instead.

The only thing about Cobol that I just can't stand so far is the optional
filler "keywords" that allows code to look sort of, kind of like natural
language. That's just wrong.

~~~
kragen
When Pascal was published in 1970, COBOL was already 11 years old.

~~~
codr7
I am aware, Cobol wasn't standardized until 1970 though.

My point is that if you can implement Cobol, you can implement Pascal; and
your users will be better off. Cobol has no inherent qualities from my
experience that makes it a better choice.

------
donkeyd
I had an assignment at the Dutch Tax Service and was surprised to learn that
they were still actively developing new software in COBOL. The reason, I was
told, was that they had many COBOL developers and not as many that were
experienced in other languages. Most of these people, however will start their
pensions in a couple of years, so they'll have nobody to maintain this stuff.

~~~
hnarn
> The reason, I was told, was that they had many COBOL developers and not as
> many that were experienced in other languages.

That doesn't sound like a very good reason when you pair it with the fact
that:

> Most of these people, however will start their pensions in a couple of years

Incredible oversight that will either lead to some potentially very serious
consequences, or some very high consultancy costs.

~~~
semyonsh
The Dutch government is unfortunately known for having IT projects fail
constantly, they've already accumulated an enormous technical debt. They
outsource a lot because the current staff is either close to retirement or
just can't be motivated anymore to put in the effort. Hearing this is the
least surprising to be honest.

~~~
donkeyd
I've done quite a bit of work in Dutch government IT and would like to add
that the failure of these projects is often because of politics and constantly
changing requirements. IT is often working really hard and doing the best they
can, but scope creep, forced deadlines and constant changes in leadership make
it nearly impossible to actually do things right.

Technical debt is also a huge issue indeed, since focus is always on
delivering new features, because that allows leadership to move to new
positions. Delivering stable maintainable code/infra isn't visible.

------
fc_barnes
My understanding is that part of COBOL's longevity stems from its particular
handling of fixed-point math being a specified requirement of various
financial contracts. Odd to see this write-up not mention fixed-point math,
actually.

~~~
nostrademons
It's been interesting to observe this impedance mismatch in practice. My first
job was writing software for a startup that sold to quant hedge funds. I did a
bunch of research on my own, and one of the best practices I ran across was
_do not use floating point to represent money_. Represent everything in terms
of integer units of the most basic currency unit (usually cents), to avoid
round-off errors. Then I took this information to my CEO, who shot me down on
the basis that all their customers used floating point for their internal
models, and so I'd be needlessly introducing friction.

And now I'm doing cryptocurrency analytics. The basic unit of Bitcoin is the
satoshi, and in the protocol, all transactions are denominated in satoshis.
(Similarly, in ethereum, the base unit is the wei and all transactions are
denominated as 256-bit words of wei.) And yet basically all exchanges are
still using floats. Sometimes they quote them as strings to avoid round-off,
sometimes it's double-precision, but internally, it's all just floating point
math. So once again I find myself doing everything in terms of floats, even
though the underlying financial instrument uses integer units of a very small
denomination.

Now that there's a huge proliferation of cryptocurrencies, I wonder if we'll
eventually see one that gives up on this point and defines money as IEEE 754
double-precision floating point numbers.

~~~
gshdg
Seems like someone familiar with inflection points in floating point
representation could pull an Office Space-style skimming scheme against a
floating point based system by perfectly legal means simply by making a lot of
transactions of carefully selected sizes.

~~~
nostrademons
Interesting idea. Most of the inflection points I've observed have actually
been at transaction/analytics boundaries. Transactions are in integer units,
analytics are in floating point. It's done this way because many algorithms
(including most linear algebra, statistical, and machine-learning algorithms)
operate on floats for efficiency, while transactions operate on ints for
accuracy.

This isn't _directly_ attackable, but you could potentially trick a trading
algorithm into performing stupid trades by feeding it subtly inaccurate data.
If you know the particular algorithm used, though, there are probably easier
ways to construct adversarial inputs and trade against them. This is why
virtually all trading shops keep their algorithms secret, and also slice up &
mix their outgoing orders randomly so you can't observe the output of the
algorithm.

------
tomlockwood
> Some banks have spent hundreds of millions of dollars and several years
> migrating systems.

The commonwealth bank in Australia, one of the biggest four banks in the
country, spent AUD$1B migrating away from COBOL.

[https://increment.com/programming-languages/cobol-all-the-
wa...](https://increment.com/programming-languages/cobol-all-the-way-down/)

~~~
flukus
I hear a lot about the uptime of cobol/mainframe based applications, but the
entire Commonwealth Bank ATM and eftpos systems used to go down for an hour or
two at 3AM every Sunday, back in the day this was nightclub close and time for
a kebab and caught me out quite a few times. It's been much better since they
migrated.

~~~
quickthrower2
Ergo you spent all your $ in the club!

------
ajxs
I'm a bit young to have had any contact with COBOL, but I've worked in
financial institutions implementing mission-critical code handling customer
transactions in other languages. The first thing that springs to mind to ask
is, what kind of features does COBOL offer to make these processes safer and
less bug-prone? At least 75% of the code and associated reams of unit testing
I've seen written in these applications is to deal with weird input and edge-
cases. Is there anything specific about COBOL that is especially suited for
dealing with this kind of task? I've never seen anything written about static
analysis or formal modelling either. Is the compiler especially attuned to
catching potential errors? Is there implicit run-time bounds checking and
analysis like in Ada et al?

~~~
krastanov
No, nothing like that. It is simply the first language ever used for these
tasks (first language to be designed to look anything like English too). The
language is so old that one of its designers is also the person that
introduced the notion of "compiler".

~~~
ajxs
Thank you, that's very interesting to know. I had guessed that there wasn't
much, based upon its vintage, but I'd have thought that it must be very robust
at some level to have dominated a mission-critical financial niche for so
long.

------
apaprocki
I was curious if anyone has published a decent chunk of “modern” COBOL since
articles and stories never really link to large working systems. It turns out
Walmart has! Enjoy:
[https://github.com/walmartlabs/zFAM/blob/master/Source/ZFAM0...](https://github.com/walmartlabs/zFAM/blob/master/Source/ZFAM007.cbl)

~~~
nn3
Interesting it has a "come from". So the execution will stop somewhere, but
it's defined somewhere else. That's worse than GOTO I would say.

PERFORM 4200-COPY-ECR THRU 4200-EXIT.

------
_glass
My day job is writing German COBOL, i.e. ABAP. The language changed a lot and
is quite usable, except they don't have namespaces. But the worst is all of
the cruft that accumulated. Not just of legacy code, but also in the language
itself. So many different paradigms, old frameworks, everything is still
working. On the other hand it is very high level for the job to be done. SQL
can be directly embedded and there is a syntax check. There are a lot of
integrated tools that are heaven and hell in the same time. The database
migrations are so easy, but source code management, deployment is hell.

------
zeotroph
Looking at the absurdly long code required to make factorials work makes you
wonder what conveniences we are all used to without really appreciating them.
And which ones will future programmers take for granted but are too niche now
- maybe async/await or the borrow checker concepts, or is programming mostly
"done"?

[http://rosettacode.org/wiki/Factorial#COBOL](http://rosettacode.org/wiki/Factorial#COBOL)

or also
[http://rosettacode.org/wiki/FizzBuzz#COBOL](http://rosettacode.org/wiki/FizzBuzz#COBOL)

Is there a code example where Cobol shines in comparison to, say, Python?

~~~
dmix
Oh no every time I visit Rosettacode I spend an hour looking up languages on
Wikipedia.

Today’s winner is dc

> dc is the oldest surviving Unix language.

[https://en.wikipedia.org/wiki/Dc_(computer_program)?oldforma...](https://en.wikipedia.org/wiki/Dc_\(computer_program\)?oldformat=true)

~~~
sparkling
I'm amazed, it is even included in the latest MacOS release

~~~
dmix
It’s like awk/sed, it has to be packaged with any unixy system.

------
os7borne
3 years ago I learned that large insurance companies in India still use COBOL.
That fact blew my mind. This fact (Estimates as high as 80% of financial
transactions use... COBOL) further blows my mind as I thought only Indian
financial institutions are rigid. Clearly not.

~~~
mrweasel
A Danish news article on the death of mainframes (or their unwillingness to
die) where they have some stats that says that 10 out 10 of the largest
insurance companies still use mainframes for they core systems. So learning
that large insurance companies run Cobol isn't that surprising.

They cite: [https://www.share.org/blog/mainframe-matters-how-
mainframes-...](https://www.share.org/blog/mainframe-matters-how-mainframes-
keep-the-financial-industry-up-and-running)

~~~
tapland
Looking at job listings over a few months this is easy to verify for the
nordic countries.

------
anotherevan
If your company is looking for training materials for COBOL or other mainframe
technology, it might be worth taking a look at Interskill.

[https://interskill.com/](https://interskill.com/) or
[https://interskill.co.uk/](https://interskill.co.uk/)

Disclosure: I work for them.

------
seventhtiger
I've heard this sentiment about Cobol often. As someone who has never seen
Cobol or used it, how hard would it be for me to specialize in Cobol
maintenance and porting? Is it really as impenetrable as it seems, requiring
years of experience, or can someone like me work through a few books and get
on it?

With this kind of thing you never know when organizations move away from the
technology en masse and it would be great to be in it at the time.

~~~
Ididntdothis
I have used FORTRAN quite a bit and I assume that the situation with Cobol is
similar. If you go into it with an open mind you will soon see common patterns
that look crazy from a more modern language point of view but were widely used
in that language. My FORTRAN code was full of GOTO which looks horrible today
but that's how things got done and once you are used to it it makes sense.

Now the other question is whether it makes sense to get into Cobol from a
career or business perspective and I am not so sure about that...

~~~
seventhtiger
Is it a bad idea? I see articles like this all the time, and job postings with
decent pay, $100k+ on Indeed. Maybe long term it's a bad idea to invest in a
technology that's bound to disappear.

~~~
NikolaeVarius
I think that it will only disappear in the sense that the heat death of the
universe is inevitable

------
RickJWagner
My first programming job (29 years ago!) was a COBOL gig. I worked for a
company that wrote banking software, most of it COBOL and a little Assembler.

It all ran on IBM mainframes (the size of a small car) surrounded by disks and
controllers the size of refridgerators. All the hardware was kept in a
glassed-in room with white-tiled raised floor. Most of the coding was done on
dumb terminals, but a few applications still had punch cards.

Ah, the memories. Long live COBOL.

------
dav
From what I understood when I worked at LiveNation, every time you buy a
ticket from Ticketmaster the transaction flows through some ancient spaghetti
COBOL, probably running in Phoenix.

------
jason_slack
I _really_ want to get a job writing COBOL. However, nobody will give me a
chance at it. I recently applied for a few jobs in my area but they wanted 10+
years of COBOL so I was turned down. I learned in college (however would need
to re-learn) and I really enjoyed it. I also enjoy financials and data.

If anyone has any thoughts I'd appreciate it. I'm currently writing c++
software for making robots work, plus I have financial industry experience.

------
Aloha
I've had a limited exposure to COBOL and I consider it quite elegant for the
problems it's trying to solve, particularly for column oriented transactional
data processing, I found it interesting that on System Z, all of the IO, is
done in the JCL that you use to start the program, not in the program itself.

~~~
throwawayForMe2
In the JCL you just specify how to link the logical IO definitions in the
program to the actual physical IO objects (real file names etc.) in the
environment. The IO statements are still in the program.

------
dejaime
I hate how the title says "powers the global economy" when it should be
"powers banking systems". I spend a lot of money on many things, my
smartphone, gsuite, slack, Netflix, Amazon, Dropbox, games, tools, hardware,
and I would guess most of that stuff never touched Cobol. Meanwhile I pay 1usd
monthly for my bank (which, btw already migrated). So saying it "powers the
global economy" is definitely a bit of a stretch.

I am sure there's a lot of it running still, mission critical stuff, also that
there are still a few teams creating new projects with it. So it is not dead
by this definition. But if I'm honest, I can't name one single language that
is.

~~~
artimaeis
When you spend the money on those things your bank or credit card merchant
processes every one of those transactions. Cobol is almost always doing the
day-end processing on those systems. Hence, while the products you use don't
directly rely on COBOL, the fact remains that COBOL is powering the economic
transactions that allow those businesses to exist currently.

~~~
dejaime
My point is, COBOL is responsible for a really small % of said value per value
transaction between me and said services. Linux, [Oracle/My]SQL, Java,
JavaScript, C, anything from router firmware to Intel cpus powering the VMs is
more relevant than said COBOL code.

So saying COBOL powers the global economy is indeed a stretch. Want to say
Linux powers it? True, Intel powers it? True. COBOL... not so much. Imagine
rewriting every COBOL system in the world, now change that into replacing all
Intel cpus, ~~SQL~~ OracleSQL or MySQL databases or Linux kernels...

Edit: saying "SQL Databases" makes as much sense as saying "procedural
programming languages", updating it to make more sense

~~~
artimaeis
Intel CPUs across the world can almost painlessly be swapped for AMD CPUs
right now and only a small fraction of users would have to change anything.

SQL is a very high level of abstraction, to the point where the argument is a
bit absurd when compared to a very concrete example of COBOL. Yes, if we had
to rewrite everything that utilized SQL then it would take an incalculable
amount of effort.

I feel like you're kind of hitting the nail on the head with the Linux kernel
bit though -- yes we could replace all uses of the Linux kernel with one of
the many alternatives available, but it would take a long time. More likely
we'd see a major transition to one of the other available kernels. This is
exactly the situation COBOL is in.

All this though -- and I think we're just talking about a semantic difference
on the use of "%1 powers the %2". Arguably C, SQL, and Javascript provide the
value to users which encourages them to spend their money which encourages
further development. So okay, I think I follow where you're coming from. COBOL
doesn't power the economy, it's just the most common form of infrastructure
for us to extract value from the economy. That sound a bit more correct?

~~~
dejaime
> Intel CPUs across the world can almost painlessly be swapped for AMD CPUs
> right now and only a small fraction of users would have to change anything.

I beg to disagree here, swapping CPUs would definitelly prove to be extremelly
costly in every possible way. Not only do the MoBo + CPUs themselves have a
cost, but they also do not exist. That would mean a huge spike in AMD (or
whatever vendor) demand, one that they don't even have the capacity to
manufacture. On top of that, all the kernel optimizations over the years,
which have a big impact in the overall costs of a cloud service, would be
lost. All that ignoring the logistical side of swapping motherboards and CPUs,
transport, risk and everything.

> SQL is a very high level of abstraction, to the point where the argument is
> a bit absurd when compared to a very concrete example of COBOL. Yes, if we
> had to rewrite everything that utilized SQL then it would take an
> incalculable amount of effort.

You're right. Let me swap that with OracleSQL or MySQL, that'd make more
sense.

> I feel like you're kind of hitting the nail on the head with the Linux
> kernel bit though -- yes we could replace all uses of the Linux kernel with
> one of the many alternatives available, but it would take a long time. More
> likely we'd see a major transition to one of the other available kernels.
> This is exactly the situation COBOL is in.

Imo the Linux kernel position is not the same as COBOL. COBOL is mainly being
maintained, whereas Linux is the current standard for new projects and will
remain so for the foreseeable future. If we create a new project running on
COBOL, or a new project running on a Linux server, those are two completely
different situations.

> All this though -- and I think we're just talking about a semantic
> difference on the use of "%1 powers the %2". Arguably C, SQL, and Javascript
> provide the value to users which encourages them to spend their money which
> encourages further development. So okay, I think I follow where you're
> coming from. COBOL doesn't power the economy, it's just the most common form
> of infrastructure for us to extract value from the economy. That sound a bit
> more correct?

Yes, exactly my point. The economy is not "powered" by banks, it is powered by
those who create economic value, and they do not use COBOL all that much.

------
sys_64738
I used COBOL when it was cool back in the 80s!

~~~
pfundstein
COBOL was never cool. A year after it was created (in 1959) people were
already predicting its demise. Yet here we are.

~~~
protomyth
It might not have been cool, but the car you could buy during the 90's working
on COBOL projects was pretty spiffy.

------
mushufasa
[https://wordsandbuttons.online/if_i_were_to_invent_a_program...](https://wordsandbuttons.online/if_i_were_to_invent_a_programming_language_for_the_21st_century.html)

------
davidw
The term from economics that describes the situation well is "switching
costs". They're very high in this case, as comments regarding banks migrating
away indicate.

This book is a great overview of the economics of these kinds of situations:

[https://en.wikipedia.org/wiki/Information_Rules](https://en.wikipedia.org/wiki/Information_Rules)

------
_bxg1
They still run it on actual mainframes? Wouldn't an emulator running on a
modern machine be many times faster?

~~~
kryptiskt
Modern mainframes are quite powerful machines: "The dual frame z14, launched
in July 2017, and the single frame z14, launched in April 2018, are based on
the z14 chip, a 10-core processor running at 5.2 GHz. A z14 system can have a
maximum of 240 Processing Unit (PU) cores, 170 of which can be configured to
the customer's specification to run applications and operating systems, and up
to 32 TB usable redundant array of independent memory (RAIM), some of which
can be configured as Virtual Flash Memory (VFM). Each PU can be characterized
as a Central Processor (CP), Integrated Firmware Processor (IFP), Integrated
Facility for Linux (IFL) processor, Integrated Information Processor (zIIP),
Internal Coupling Facility (ICF) processor, additional System Assist Processor
(SAP) or as a spare."

[https://en.wikipedia.org/wiki/IBM_zEnterprise_System](https://en.wikipedia.org/wiki/IBM_zEnterprise_System)

~~~
_bxg1
I assumed "mainframe" automatically meant "computer from no later than the
early 90s", since these days we just call them servers. Similar to how I'd
assume "microcomputer" automatically means "desktop from no later than the
early 90s".

~~~
illirik
There's a number of big differences between a modern IBM mainframe and
commodity servers. For one, the architecture:
[https://en.wikipedia.org/wiki/Z/Architecture](https://en.wikipedia.org/wiki/Z/Architecture)

------
xxxpupugo
...because people aren't willing to change it.

That doesn't make Cobol sounds less like a fossil in any way. It will be go
away eventually.

------
beigeoak
What an incredible website

The audio version has the quotes in the voice of the original speakers
(probably because this is a radio).

There is an interactive timeline custom made for the content of the article.

Other audio logs can be accessed super easily via the drop down menu.

Incredible stuff.

