
It’s COBOL all the way down - mooreds
https://increment.com/programming-languages/cobol-all-the-way-down/
======
aetherspawn
Ok, let me just say at work I’ve spent the last 4 years working on a product
that interfaces with COBOL. In-house we:

\- Generate native windows interfaces with COBOL, to the point where only a
few lines of code create a control like a data grid, button or text entry with
rich functionality. You’d never know these snappy native apps, with features
like visual data validation and asynchronous menus/context popups, are COBOL.

\- Render rich web pages with COBOL using a in-house DSL that automatically
become somewhat responsive between devices. The presentation information
streams over a web socket so it’s snappy and as responsive as the above
desktop application

\- Perform complex queries and rich data validation. A few lines of code can
automatically be linked to grid view that has HEAPS of built-in functionality
like export or data side-view (link applications/side panels to the currently
selected row), app row highlighting and styling, auto pagination with range
expand, column sorting, reorder, filtering, conditional highlight and more.

So yeah, COBOL isn’t dead. It’s actually the coolest damn thing Ive seen in a
while. Because it’s pretty high-level we can build whatever we need on top as
a runtime and the same apps can run on the web, native desktop, handheld
tablet or on an old VT100 over SSH.

~~~
holocen
Can you point to any accessible versions of this? I’d love to check out an
example, sounds really interesting.

~~~
aetherspawn
Unfourtunately not, it’s part of a very expensive ERP package. But this
article has a few screenshots:

[https://www.scopesystems.com.au/whats-new-pronto-
xi-740-scop...](https://www.scopesystems.com.au/whats-new-pronto-
xi-740-scopetalk/)

~~~
lytedev
Is this really all the same COBOL application? I'm truly impressed! Is there
some kind of GUI toolkit for COBOL or the COBOL in this case only the logic
behind the application and the GUI here is another language/framework?

I ask because your parent comment certainly rings true if this is all COBOL!

------
kimi
I worked in insurance so much time ago, in a COBOL shop (I was doing web-
services on top, so I'm not a COBOL programmer myself). A few things come to
my mind:

\- COBOL has no stack and no dynamic memory allocation. The memory cost of a
procedure is known in advance and you cannot leak memory. There is not much
room to be smart, and in the long run it's likely a reason for success. You
would not want people with a three month training editing 20-yr old C code.

\- COBOL procedures are damn CPU-efficient at what they do

\- COBOL works in symbiotic relationship with DB2. A lot of things that are
complex/tiring to do in COBOL (like e.g. working with strings...) can be done
in SQL. And when you have SQL you can do pretty powerful things.

\- COBOL procedures do not usually sent SQL queries as strings to the
database. They compile down to a procedure that does physical, low-level
handling of database tables. If you change a table, you have to recompile all
procedures that depend on it (and it may take hours to days....) but again is
damn efficient in production.

\- mainframes run _constantly_ at a CPU usage of over 90-95%. There is a huge
amount of procedures constantly running to maximise the return on the system.

~~~
pkaye
> COBOL has no stack...

So no function calls?

~~~
nafey
Although I am not familiar with COBOL I am assuming this means you have to
indicate where the control returns to after a function ends

~~~
jrq
So that's kind of like a coroutine. Taking recursion away seems like an
unnecessary limitation, considering how much power main frames have. Resource
efficiency is great and all, and certainly there's a benefit to not hammering
the stack as often, but that takes away an entire category of definitions you
can't express, right?

Maybe someone who writes cobol could chime in on this.

~~~
kbp
> Taking recursion away seems like an unnecessary limitation

Modern Cobol doesn't seem to have this limitation, eg
[http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/handhel...](http://publibz.boulder.ibm.com/cgi-
bin/bookmgr_OS390/handheld/Connected/BOOKS/IGY3PG20/4.1.4). When Cobol
originally appeared, call stacks weren't standard, Lisp didn't exist yet, and
neither Fortran nor Algol supported recursive functions; it made sense at the
time.

~~~
jrq
Ohhhhhh, of course!

Gosh, thanks. I sometimes hold historical technology to unfair standards
because I'm not thinking about the continuity of it all.

Crazy to think twenty-somethings are out there hacking COBOL!

------
Yhippa
I actually appreciate the fact that COBOL, while verbose, lets me scan the
source code and get a general understanding of what it does.

Just did a migration from a mainframe to Java microservices. We were lucky to
have subject matter experts on hand so we didn't have to delve too much into
the COBOL code. Used JHipster Domain Language Studio to quickly go from a
Bachman diagram to an entity domain model.

One quirk was that we were not permitted to use a modern UI; we had to emulate
an IBM 3270 screen! The client ran out of money for retraining users so we had
to do a lift-and-shift of the UI.

~~~
twic
You drive the terminal with one microservice per character, obviously.

------
Volrath89
I'm a young developer who also happened to work in a bank so I did a lot of
Cobol in 2017-2018.

Good points of Cobol:

\- No boilerplate

\- You could understand the use case just by reading the code

\- Never seen such a fast processing of millions of records (this was done
with VSAM files)

But the most important and a real eye-opener for me:

\- Any developer can easily learn how to program in Cobol. You don't need
superstars 10x programmers and ever changing frameworks and paradigms. There
were grandmothers working as developers in the bank. I've actually never seen
such a diversity in IT (not only age but also gender diversity). And you know
what, that made it a real nice place to work

~~~
kayla210
I'm also a young developer that works with COBOL, but I work in the insurance
sector. The environment you describe is also how it's like here. And I've
never worked with such nice and intelligent people!

One thing I really love about this environment is you learn a lot about the
business area when working with COBOL, since the business logic is so plainly
written in many programs. I don't like using the term "self-documenting code,"
but COBOL is really close to that.

------
SmellyGeekBoy
Speaking as someone who occasionally gets roped into supporting a COBOL
application at a large financial institution, I genuinely don't get the "we
must replace it because it's old!" mentality. If it's still the best tool for
the job then why move away? Just train people up and build tools to work with
it on modern systems, just like Micro Focus and COBOL Cowboys (both mentioned
in the OP) are already doing. As an added bonus, you can make a lot a money in
the process too.

"The guy who wrote it left and nobody knows what it does" is a poor excuse
with a self-documenting language like COBOL. How much sense do you think your
tangled mess of Java will make in 50 years?

~~~
pmilot
While I generally agree with the "if it ain't broke" sentiment, you have to
perform some pretty wild mental gymnastics to end up calling COBOL the "best
tool for the job".

Adoption and ease of learning should always be considered when selecting a
tech stack for a solution. COBOL's semantics are so foreign to modern
programming languages that it makes the language pretty inaccessible.

Also, COBOL's strength is in the generation of reports, but in the end, it's
no more expressive for that purpose than any general-purpose programming
language coupled with a nice report generation library.

~~~
coldtea
> _While I generally agree with the "if it ain't broke" sentiment, you have to
> perform some pretty wild mental gymnastics to end up calling COBOL the "best
> tool for the job"._

Do you? Lack of programmers, aside, it was created and evolved exactly for the
kinds of jobs its used in.

~~~
ams6110
It is something of a DSL, as the name suggests (Common Business Oriented
Language).

I would also disagree with GP that COBOL's semantics are really very foreign.
Variable declarations, assignments, expressions, loops, conditionals, etc. are
not that different from other imperative languages. More verbose, certainly,
but not foreign.

JCL on the other hand....

~~~
floatboth
If it's similar to other imperative languages, what makes it a DSL? What _is_
the domain of "business"?

~~~
coldtea
It's similar to other imprative languages in some constructs, it's very
business application focused in others -- e.g. built-in support for forms, for
monetary calculations and such.

------
grewil2
After years of struggle, our IT-department recently managed to conclude the
migration of all COBOL applications from machines running on Unisys 2200 to
Java EE running on GNU/Linux. As a Java developer working with the latter, the
final months were wild. The old COBOL greybeards (some 70+, convinced to stay
until migration was finalised) certainly didn't go gently into that good
night, literally throwing insults at us, leaving meetings, wishing us bad luck
etc. We could never be sure they had given us all information about their
stuff, out of spite. I hope I don't finish my working years like they did.

~~~
duncan_bayne
So, how was your IT department treating them at time time?

As valued employees, pairing with the Java devs on code, attending team
lunches and other functions, generally integrated with the teams to which they
were passing on their life's work?

Because to be honest I'm struggling to believe they were being treated as
equal members of a team if they were behaving like that.

~~~
KWD
I think the statement "convinced to stay until migration was finalised"
already answers your question. I'm sure there would be some that would have
wanted to, and been capable of, picking up a different language, but that is
not how companies do things. It's replace with the new, even though a lot of
business/application knowledge could be retained otherwise.

------
codenesium
I did COBOL for two years out of college. It is the most frustrating and
terrible language to work in. We weren't using it on a mainframe we were using
it to build GUI apps that run on client machines. I would spend days writing
code that would take 20 minutes in c#.There were 10k line files with all
global variables and you might think it was just bad design and what not but
the team was very disciplined and focused on quality. There are no tests,
documentation or Google queries to help you. Your job is to dig in an enormous
codebase to understand what it does and that is tough. The developer output
compared to a modern language is tiny compared to a Java or .NET developer.

~~~
commandlinefan
> I would spend days writing code that would take 20 minutes

And then weeks debugging the phantom problems caused by the overuse of global
variables that COBOL more or less mandates... I feel your pain, brother.

~~~
protomyth
I know it isn't cool, but I often wonder if anyone will come out with a
language that isn't meant to be the next C but the next COBOL, RPG, etc. I
wonder if anyone has a LLVM backend for z/Architecture and TIMI.

~~~
evincarofautumn
That’s a problem I’ve occasionally considered working on—modern alternatives
with tractable, incremental migration paths away from COBOL/RPG/MUMPS—but I
hardly know where to begin.

I’m sure for a lot of these companies, due to the sheer size and often
mission-critical nature of these systems, the cost analysis still comes down
on the side of keeping the COBOL/&c. systems and just using new tooling around
them, like static analysers, integrations with frontend frameworks, ways to
interoperate with relational databases, and software emulation of mainframes.

An alternative would be not only difficult to build but hard to sell. There’d
probably be a lot of money in it if you had a team with the financial runway,
technical skills, and market connections to do it, though.

~~~
protomyth
I've thought about it a bit, and I do wonder if defining a VM and compiling
the COBOL/RPG/MUMPS to it first then building the language off that. The
languages are pretty straight forward and defining a decent high level VM
instruction set would probably help with the not only the conversion but
provide some assurance that you didn't miss something important.

------
ibiza
It would be a nice surprise to come across an article on COBOL that has
anything nice to say, much less informative, about the language. One could
start with that it's one of a tiny minority of languages based on decimal
arithmetic as opposed to binary. This is kind of handy when dealing with
money.

~~~
labster
Perl 6 uses rational arithmetic by default (or by defining typed variables),
which covers the money use case well. And, of course, we have SQL's DECIMAL
type in most backends.

~~~
nothrabannosir
And Common Lisp, although it’s not necessarily “default”. (/ 2 3) works as
expected, but 1.7 is a float (unfortunately), and not a rational 17/100\.
Shame, really.

~~~
Grue3
Nothing unfortunate about that. When you work with rationals, it's very easy
to grow incredibly large denominators, at which point all arithmetic
operations slow to a crawl. Floats are fast and predictable, which is why
they're used for most calculations in CL and other languages.

~~~
AstralStorm
Except when you hit denormals or underflow. Or accidentally lose precision
ending up with a wrong result.

If I could get a cent for every money transaction done on floats and
incorrectly rounded, I'd be a billionaire.

------
JimmaDaRustla
I wrote the Apple Pay DPAN provisioning message tokenizer at a major financial
institution in COBOL. Messages came through the payment network backend
(BASE24) and our systems are all mainframes. COBOL will never go away until
our major financial institutes are obsolete.

I met with manager to, what I thought was, to discuss the project and I
brought up that tokenized PANs were our opportunity to transition off the
mainframe and that we missed the boat. It fell of deaf ears because our
meeting was actually to discuss how I was being reprimanded for using an SSH
connection which the company couldn't perform a MITM attack on. It was at that
point I knew I could not advance my career there.

~~~
jxsonl
You got reprimanded because the company wanted to perform a MITM attack on
people? (sorry I got confused on the last line and wanted to be sure)

~~~
WorldMaker
It sounds like they were having trouble doing their job because their
corporate IT decided it was more important to intercept all TLS/SSL traffic on
the corporate network than to allow software developers to do their job
securely.

They weren't MITM attacking people outside the company, just MITM attacking
their own employees.

I feel that pain, quite often (and am slowly losing a war on it at my current
employer, sigh). TLS/SSL Interception Proxies are scum that make the internet
overall less secure for a weird sense of security by corporate IT departments.

As a software developer, it's my job to make sure that no one is MITM
attacking me so that the code I download to incorporate into projects is safe
and secure. I can't check if a bad actor is MITM attacking me when my own
employer is MITM attacking me.

~~~
jxsonl
> "It sounds like they were having trouble doing their job because their
> corporate IT decided it was more important to intercept all TLS/SSL traffic
> on the corporate network than to allow software developers to do their job
> securely."

Right, that was what I thought too, this is honestly why I'm turned off from
applying to work with more bureaucratic companies (soon to be fresh graduate),
I understand the reason for sensitive informations being leaked. But this
seriously causes a lot of productivity loss...

I've interned with a small company that needs to SSL into government/companies
servers to do work. (I don't do them, just on local company machine for
testing etc. Also maybe why they can't let me do live site related stuffs)
It'll be a big pain to not be able to SSL remotely and do work.

------
yagyu
I have an uncle who's about to retire after a career as a cobol dev. He tells
me that he can teach me the language in two days, show me around the legacy
systems of [big company you know] in two months, and then I could have a safe
and lucrative career until I retire, too.

I wish he was interested in writing a blog post of war stories.

~~~
ams6110
COBOL is easy to learn if you already know how to program. What's a bit harder
is learning the mainframe environment it's deployed in. It's not like Unix or
DOS at all.

~~~
kayla210
Yes, this exactly. Whenever I tell people I'm a mainframe developer, they
always ask how they can learn COBOL. Oh, that's the easy part. The environment
is very different and takes a while to get used to, but it's where COBOL
thrives.

------
hestefisk
Today, Commonwealth Bank of Australia (as mentioned in the article) has indeed
successfully migrated to SAP Core Banking. Westpac is in a similar
transformation to Oracle Core Banking. Some European banks, eg Nordea, are
slowly moving to Temenos T24, a Swiss java based core banking system. Danske
Bank built their own. It was expensive and, afaik, still has issues.

~~~
auvi
Are there open source core banking software out there?

~~~
oblio
I don’t think banks are famous for sharing (or caring :) ).

~~~
bigato
They probably don't share much nowadays, but look up CBT tapes for an counter
example of Banks doing open source and code sharing before it was a thing.

------
donkeyd
> billions more being written each year for maintenance and new features

This is funny to me, because the where I'm working right now, they have teams
building entirely new projects in COBOL. The reason is that it's a company
with a very high average age and incredible secondary benefits for baby
boomers (old contracts, young people get ripped off), so they have an army of
COBOL developers while there's a shortage for pretty much every other type of
dev.

~~~
oblio
Yeah, but what will they do in 10-15 years? Those people aren’t immortal and
newcomers will have to be:

* persuaded to come: tough sell for Cobol

* 99% internally trained cause the pool of Cobol devs is probably similar to that of Elm devs :)

~~~
dmitrygr
This problem is solvable by basic market dynamics. When everyone knows that a
JavaScript "Dev" can make $80k and a cobol one can make $190k, people with
learn cobol. It isn't hard. If you can grasp one imperative language, you can
grasp any of them.

~~~
oblio
True, but if the Cobol market is for 10k developers worldwide, not many people
will venture there, even for higher pay. Cause if you get fired from your
Cobol job and there’s no openings for Cobol devs, your market value just
plummeted to $40k as a Junior Javascript dev ;)

And despite what we may think, except for the big tech companies, everyone
else doesn’t really hire generalists. You could have 20 years experience as a
programmer in 10 different languages, HR still wants a Java programmer with 5
years of Java experience.

~~~
collyw
Fuck it, I am sick of the churn associated with modern development. Cobol
sounds quite appealing right now.

~~~
adrianN
You could also become an embedded dev. Write software for cars or planes, or
train, or nuclear power plants. If you want you can work on the same piece of
software using the same tooling for your whole career.

~~~
collyw
Whats the language of choice for that? C or would Rust be worth learning? Any
pointers for how to get started in that field?

~~~
murph-almighty
(heh pointers)

I was in ECE in college (graduated in 2017) but do full stack software
engineering for a bank now. AFAIK it's still C, but I wouldn't be surprised if
Rust picked up due to the emphasis on memory safety- dynamic memory allocation
and recursion are usually avoided in embedded.

Some of the lessons I got from embedded have carried over to my place of work-
I found a repo that used floating point for money and immediately knew why
that was a bad idea, because my embedded systems professor had spent an almost
an entire lesson explaining why you don't use floating point for money or
time.

side note: Said professor (Phil Koopman) was an expert witness in the Toyota
unexpected acceleration lawsuit, he has a talk on it that can be found at
[https://betterembsw.blogspot.com/2014/09/a-case-study-of-
toy...](https://betterembsw.blogspot.com/2014/09/a-case-study-of-toyota-
unintended.html).

------
kristianp
Is it really better if we replace x million lines of COBOL with x million
lines of java or c++? What is the financial language of the future that is
easy to write and reduces errors?

~~~
EdiX
It would actually be better if we replaced x million lines of COBOL with x
million lines of COBOL. For many reasons:

1\. it would run on a modern environment instead of a weird mainframe OS using
a weird database

2\. it would use modern coding conventions such as local variables and control
structures instead of goto

3\. it wouldn't be x million lines after you remove all the dead and duplicate
code. These are codebases have been developed for 3 decades with the principle
"we don't know how any of this old shit works, don't touch anything you don't
need to"

But yes, you would also get a lot of advantages from porting everything to a
modern programming language with good tooling.

~~~
tluyben2
I agree with you somewhat there; you mean refactor instead of rewrite and yes,
I believe that is a better choice. But the problem is not language related;
Joel Spolsky said it with far smaller and more modern codebases, but, as you
even indicate within #3, 100000s of changes were done in the code over 30
years by people who did not understand the full system or, often, did not even
understand the local parts they are editing fully. A lot of changes in legacy
code, but let's not kid ourselves, also in modern code, depend on 'things' the
programmer deemed right at that moment. Then after testing (even testing in
practice with people's money), now after unittests (or in practice, with
people's money), too much of the business logic/functionality depends on bad
code. Code that is off-by-one that isn't discovered for decades or at all is
not unheard of for instance because that routine is only triggered for a
specific insurance policy only 100 people have and for those 100 the bug
actually gives back the right answer. It would require deep understanding of
all the corner cases and that's why it's often just not rewritten.

We were working, around 2000, on partially porting a Cobol+Fortran insurance
system (which was an 'integration' of systems acquired by acquisition over the
years) to Java (yes, EJBs..... ..... ..... the sins of my youth...). The work
was mostly 20 people working for months on creating all the encoded rules into
spreadsheets and, in a much shorter time, us translating those to Java. This
particular piece was done because the company wanted to webify that part of
the system. I am not sure if the modern versions of 'software mainframes' or
modern hardware mainframes would be fast enough to handle web with the old
code running?

~~~
ams6110
The thing about most old COBOL is that there is very little shared code. There
are things called "copybooks" which are snippets that get copied into your
program at compile time, but they are not "shared" code. So you have much less
chance of affecting anything else when you change a COBOL program. Most are
written to perform a single transaction or generate a single report or screen,
and are entirely self-contained.

------
mcafeeryan92
Anyone have thoughts on how to go about learning mainframe programming and
COBOL? Honestly seems like a useful skill given its existence everywhere but I
don't think very many engineers (myself included) know where to start in
learning it.

~~~
bartread
A number of people, I think in the "COBOL Cowboys" discussion, on HN have
pointed out that it's not learning COBOL that's the issue. The language is the
easy part. The real problem is learning the mainframe systems and concepts,
and especially gaining meaningful experience with them. Emulators are
available in some cases but back in the day all this stuff was proprietary,
and doesn't follow the familar UNIX-a-like mould of many modern OSes. (It goes
without saying they're nothing like Windows, either.)

EDIT: I think this is the COBOL Covboys discussion I referred to above:
[https://news.ycombinator.com/item?id=14083214](https://news.ycombinator.com/item?id=14083214)

~~~
calt
Yes. I agree with this. Having command line and interactive terminal
experience and actually programming your environment the more fundamental
skill to have on mainframes.

~~~
ams6110
I don't know -- It's been decades since I wrote any COBOL, and at the time I
was pretty fresh out of a unix-centric undergrad environment. I was at home in
emacs and the shell command line and familiar with unix utilities, but the
mainframe was just another planet entirely. None of that experience really
translated.

------
orbital-decay
COBOL code base is pale in comparison to modern systems, and mostly self-
contained. The number of critical legacy systems written in ancient languages
nobody supports anymore is going to increase, and given the reliance on third-
party code (libraries, compilers, frameworks, tools etc) the problem will be
much more prominent in several decades from now, when all current programmers
retire and the institutional memory should kick in.

~~~
ofrzeta
> The number of critical legacy systems written in ancient languages nobody
> supports anymore is going to increase, and given the reliance on third-party
> code (libraries, compilers, frameworks, tools etc) the problem will be much
> more prominent in several decades from now

You're talking about Javascript?

~~~
orbital-decay
AFAIK Javascript is not used for critical systems which will be in service for
decades. Besides James Webb Space Telescope, of course.

~~~
alephnil
I don't know if you are serious, but regardless of that, the James Webb space
telescope will stay near the L2 Lagrange point. This is not a stable orbit,
and left to its own, the spacecraft will drift away from the desired orbit.
That means it needs thrusters to keep itself in place, and it will bring
enough fuel for about 10 years of operations. After that it will slowly drift
out of L2. Given the distance from earth, there is also no way there ever will
be any service missions that the Hubble space telescope relied upon.

So no, James Webb space telescope won't be in operation for decades.

~~~
orbital-decay
It was mostly a snark. Yes, you're absolutely right, JWST service life is
propellant-limited, not to mention its limited liquid helium supply for the
first phase of the mission. And they are not using pure ECMAScript either,
it's a heavily customized version.

------
gormz
>The language ostensibly self-documents, because it’s so verbose and requires
so many explicit declarations about what it’s doing

You know, I just finished a COBOL class at university and this makes sense.
One of the main things I hated about cobol was how strict and weird the syntax
was. It uses so many full verb identifiers rather than just operands. The
language just really feels like it was built to be rock solid.

------
derefr
Few people want to program in COBOL; but businesses still depend on _running_
COBOL code. Reminds me of another language: JavaScript.

The developers who didn't want to code in JavaScript, solved the problem of
having to _deploy_ JavaScript by creating other languages that compiled _to_
JavaScript: CoffeeScript, TypeScript, Elm, ClojureScript, etc. And, more
recently, by just turning the JavaScript interpreter into a glorified low-
level VM, through WASM, so that it can be programmed in _any_ language.

Why hasn't this approach been taken with COBOL?

With such a language in hand, you _could_ take existing codebases (or compiled
binaries) and write a decompiler that would convert them to your language of
choice, so that the whole project could exist in the new form. Or, more
simply, you could just write new modules (and rewrite any modules you have to
change) in the new language, leave old modules as COBOL, and then link them
together.

------
xioxox
This is timely given the terrible problems the TSB bank is having after
failing to properly transition from a legacy COBAL system
[http://www.bbc.com/news/business-43948889](http://www.bbc.com/news/business-43948889)

~~~
gaius
You mean, transition from a fully working COBOL system that their former
parent company is happily using, to a modern one that shows
NullPointerException to the end user?

~~~
PuffinBlue
> happily using

Not sure you can say they are 'happily' using the agglomeration of bolt on
systems that they have pulled in over the years.

There's remnants of Cheltenham and Gloucester, Halifax, Bank of Scotland, TSB
(now spun out), Scottish Widows, Standard Chartered Bank (IIRC) and I think
some parts of Abbey National.

Those are just the one I remember and some of those are comprised of a mish
mash of prior systems.

Keeping all that going is likely a huge burden. Indeed, they charged TSB £100
million a year just to emulate TSB's part of the system so TSB could just keep
using that until their subsequent merger.

~~~
twic
Santander bought Abbey National. Did some of it end up in TSB somehow?

~~~
PuffinBlue
I just looked it up - I got confused as it was Abbey Life not Abbey National.

------
fizixer
> He also noted that billions of dollars would likely be needed to implement
> this kind of migration across multiple agencies.

> You can’t just rewrite the whole thing.

Is it that bad? I guess I'm being crazy thinking I can do it single handedly
in 5-10 years for a couple million.

~~~
vorg
> I can do it single handedly

For every 1 programmer working on a Cobol system who would and could rewrite
it, there's another 3 who actively resist rewrites to keep their jobs and put
bugs in the system to generate overtime-paying after-hours callouts. There's
yet another 6 programmers who don't have the aptitude to program but who
somehow managed to get into their job and are just productive enough to avoid
being terminated. And perhaps they bring one of their kids to work for the day
every now and then.

You don't get to do a Cobol rewrite single-handedly when there's 9 others on
the team working against it happening.

~~~
fizixer
I agree.

But that also means the major roadblocks are sociopolitical and not technical
(not saying technical challenge is not there, just that it's not the biggest
issue).

------
notacoward
If COBOL is really as self-documenting as everyone seems to claim, why is it
not possible to translate it to some other language and then use that version
going forward?

~~~
christophilus
It is possible. I did it early in my career, fresh out of college. It wasn't
hard, just tedious.

I think (total speculation) that the root cause of failure in these projects
is due to mismanagement and (maybe) the kinds of people who are pulled into
the projects. To the latter point, it's really hard to attract great developer
talent into such a project, same goes for medical systems and government
contracting. There's better money, and _way_ better work environments in other
sectors. (Just my 2 cents.)

------
gtycomb
The puzzle is, when and how will this state of affairs (running legacy
technology) change. Is it because C-suite movers and shakers doesn't have
skills to bring about change? Or is it that things we take as trusted and
agile modern systems and methodologies discussed here in HN happen to be
things that the market at large will not bet on for a forseeable future.

~~~
kryptiskt
Replacement projects for big legacy technology stacks have a track record of
costing huge amounts and then not delivering. So keeping them running for as
long as possible can be perfectly rational.

------
nwsm
I took two semesters of mainframe classes (COBOL, JCL, DB2, etc) as electives,
in 2015-16. I wouldn't want to do that full time (though the jobs are there
and it's an applicant's market), but it was a great experience.

So much different than all my other CS classes, and gave insight into an
important part of IT that isn't really taught anymore.

------
Tistel
Neat article. I am quite old but never touched COBOL (they used Java to teach
in Uni). There are so many articles about the failures of transitioning on
legacy system to a modern one. Like that British bank going over to a Spanish
one (TSB?). Does anyone know of success stories? What were their
techniques/strategies?

When I hear about the COBOL line count it always makes me think that someone
should write a program that eats COBOL as input and spits out
Java/C++/LangDuJour as output. Might make a good company. Mind you, it may
already exist, or, be impossible because of some aspect of the COBOL language
I don't understand.

~~~
ecshafer
Microfocus has a cobol to jvm transpiler.

Issue is that cobol often relies on intricacies of specific mainframes or
cobol implementations so it's never quite that simple.

Also a lot of cobol directly interfaces with databases with side effects which
makes it ever harder.

~~~
tolle
Micro Focus is an interesting company. And apparently very profitable. From a
smallish company making tools for mainframe development and consultancy to now
owning HP Enterprise and a whole bunch of other companies as well. They're
raking it in money wise.

------
hestefisk
And worth noting the real pressure comes about when you move to real time
payments. COBOL / mainframes are batch transaction processing systems and
generally struggle with real time / event based transactions.

~~~
zhte415
That's what CICS is for, and has been around for quite some time
[https://en.wikipedia.org/wiki/CICS](https://en.wikipedia.org/wiki/CICS)

------
PaulAJ
I'd take a guess that the recent problems with the TSB migration are down to
something like this. (Google it if you haven't heard). They tried to replace
lots of ancient systems with a big new one and ... it didn't work.

Root cause on something like this is problematic: management instituted a hard
deadline despite signs of serious problems early on, and there seems to have
been some monkey patching being applied to live systems as they try to get it
working. But a big factor has got to be the huge problem of figuring out what
all those old legacy systems actually do.

------
hyperman1
My company has plenty of Cobol. While I am not on their part of IT, I used to
work together with them for integration. I left with very mixed feelings.

Some bad sidess * The language is old, in a bad way. Reading cobol learns you
pretty fast why todays practices are better than the multi million spaghetti
monster of the past. * IT practices are old. They havent yet embraced lower
case. I trieds to tell one of them about UTF-8, but the whole idea that 1
char=1 byte might not be an universal truth was so far out she immediately
rejected me as insane. * IT tooling is unique. These guys did CI/CD in the
80ies, but did it with a whole custom stack. They wrote their own source code
control, and added an engine wih auto compiles checked in code, rejects code
not according to the very strict rules, does some testing, and manages
promotion from dev to test to preprod to prod. * The database consists of 12
files (we would call them tables). Each of them has exactly 1 index. You
either do a full read or an indexed lookup. There are no more files left, they
are used up. Quite a lot of nightly batches exist for looking up data not
reachable by the index by doing a full read for each record. See it as a kind
of manual join. * Security practices are old. There is no isolation, every
application has full access to everything (There is 1 mainframe shared between
user data, HR data, payment systems, ...) . If an application crashes, it
dumps core. This is considered a feature, as the user can restart without much
trouble. The idea that a dump might indicate some kind of exploitable problem
is incomprehensible, so it is a continuous fight to keep these guys from
connecting cobol straight to the internet.

But even if the technology side is horrible, they provide a lot of business
value, especially compared to modern oracle/sap/tata/... 'enterprise class'
applications: * The terminal application is quick, even if the learning curve
is horrible. You just type as fast as you can. If cobol cant follow, you'll
see a pause on the screen, but don't let that slow you down, the mainframe
will catch up. * There is no sexism here. The male/female mix is approx
50/50\. * These guys know their business. Every edge case of an edge case is
known. Compare that with the enterprise applications, where every release
proves within a week to be hopelessly unfit for business purposes. We have to
throw millions at the new applications just to keep them limping along. *
There is no hubris here. No Architect, no Consultants, no expensive management
ideas. A recent migration from cobol to oracle OSB+gui actually required us to
add 1/3 of personnel to account for the slowdown caused by people . Yeah we
all saw it comming, those wo reported problems were not given raises until we
got the message. But cobol culture is 'That can't be done', after which the
Architects recoil in horror and let them be.

All in all, Im not sure if this post is an argumant for or against Cobol

~~~
collyw
Out of interest what do you see as the benefits of UTF-8 in source files?

It has caused me problems a couple of times, and I don't ever think I have
needed anything outside of ASCII for source code, with the exception of
entering some foreign names in to a database via a script.

~~~
hyperman1
Sorry, that post got horribly mangled.

I want UTF-8 in the database, not the source files. This is Europe, user data
has accents aplenty.

This once ran on a real mainframe, but was then migrated. So it has the common
subset of win1252 and some ebcdic variant, minus lowercase. No euro sign on
the financial report anywhere ;-)

------
rauhl
Weirdly, I submitted the exact same URL 20 hours ago:
[https://news.ycombinator.com/item?id=16958811](https://news.ycombinator.com/item?id=16958811)

Not complaining, just surprised: I thought that HN deduplicated within a few
days or weeks.

------
tankerdude
COBOL maybe alive but from doing a little bit of searching, the pay scale
looks like about half of what a senior engineer in a more modern language
makes.

------
halfnibble
I like studying computer programming history and I'd love to become proficient
at COBOL and work on old mainframes! Where do I sign up?

------
rudolfwinestock
I've noticed that people only speak well of COBOL when Grace Murray Hopper's
name occurs nearby.

I suspect that this says something about COBOL.

~~~
xenadu02
Grace Hopper is a legend not because the tools she invented are great by
modern standards, but because she laid the groundwork. She was also one of the
earliest to recognize how important computing was going to be and that hand-
writing everything in hex was not a great idea. Later she championed even
higher-level abstractions. Programming at the start of her career was
considered non-creative secretarial work for women to do, which has the
dubious distinction of being wrong and sexist at the same time.

When judged by standards of the day COBOL wasn’t bad. It was one of the first
examples of a high-level language. People’s experiences with it (and large
undocumented spaghetti logic programs) helped inform the next generation of
languages.

Later our (ongoing) experiences with the unsafety of C led to Java, C#, and D
among others. Further reactions to those are Swift and Rust.

I’d argue we wouldn’t have any of those languages in the same form without
COBOL.

~~~
Retra
>When judged by standards of the day COBOL wasn’t bad. It was one of the first
examples of a high-level language.

Compared to LISP?

~~~
slx26
> COBOL (Common Business Oriented Language)

You can't compare the languages like that, they were created to fill very
different roles, and both were very successful at what they did.

------
Bromskloss
Is the pay stellar? If so, I could do COBOL.

