
On COBOL - MindGods
https://www.oreilly.com/radar/on-cobol/
======
mercantile
If you don't know COBOL, Wikipedia has a pretty excellent overview of a lot of
its basic syntax here:

[https://en.wikipedia.org/wiki/COBOL#Features](https://en.wikipedia.org/wiki/COBOL#Features)

It's very verbose, and includes a lot of opaque language that almost seems
designed to confuse (I know it wasn't actually, but it's pretty bad). For
example, an alphanumeric variable type is called a `PIC` for "PICTURE". You
can store an alphanumeric as a `PIC A`, or a numeric-only using a `PIC X`.
Fields in a record get a "level number" that defines their behavior, and you
just have to memorize which does what. 01 is a top-level record. 05 defines a
subgroup. 88 is a conditional record.

There are many parts of the language that are clearly anti-features in
retrospect. A 66 level number allows you to redefine a field in a previously
defined record. Convenient in some cases maybe, but something that will
clearly lead to maintainability problems as the shape of a record doesn't
match its original definition in code. Another example is that COBOL has a
huge vocabulary, with the original idea that you could write things as much
like English as possible (e.g. use a `GREATER THAN` instead of a `>`), which
is one of those things that probably seemed like a good idea at one point, but
which every modern language has abandoned or is abandoning (through the use of
linters, etc.).

The article makes quite a few salient points, but on the other hand, if
there's ever been a language that got almost everything wrong in about as
objective a sense as you can get when speaking about these things, it's this
one.

Instead of inspiring the next generation of COBOL programmers, IMO there's a
good alternative argument to be made for getting a bunch of smart people
together to write a transpiler that could transform huge legacy COBOL
codebases to something more maintainable, like how the Go team transpiled from
C to Go, and vanquishing this language to the history books. Obviously very
difficult, but something that'd pay off in the long run.

~~~
Smoosh
Sorry to criticize, but as a daily maintainer/writer of COBOL, your
characterization is a bit off. Besides technical inaccuracies (PIC 9 is for
numerics, 88 is a conditional value in a field) you don't seem to grasp what's
truly right or wrong with COBOL. Nor does the article. For example, ime no-one
uses 66 levels, as the REDEFINES clause achieves the same result. While there
_can_ be issues with maintaining code with overlapping definitions, _their use
is deliberate_. For example, data read from a file could have two or more
different record structures. It is read into one place in memory and the
redefinition applies different formats/views to the same memory. The correct
one is used as needed. There is no problem. You might be right that there are
some anti-features, but like GOTO they simply aren't used in real codebases.

The real problem with COBOL imo, is that the language hasn't much improved
since it's creation. While there have been some useful tweaks and changes, it
has missed out on major items such as variable scoping/user-defined functions
(all variables are global - the workaround is to use sub-programs and pass
data in the call). Even "object-oriented" functionality as mentioned in the
article was badly tacked on to the language and only complicates it without
really adding much in terms of capability. Also, the language doesn't really
have strings as in other languages, and consequently lacks the applicable
functions.

Another major point that the article misses is that mainframe COBOL (most
COBOL is/was mainframe and that means IBM) which does anything more than
straightforward "read file,process contents,generate report" is inextricably
linked to its environment. The article talks about poor form handling. COBOL
doesn't do form handling. That would be CICS or IMS/DC software which the
COBOL interfaces with. There is heavy integration in the code, but this is
like confusing Java with Websphere or Tomcat. This is why it is so difficult
to port COBOL systems to another language/environment. The COBOL code can be
mechanically converted. But any complex system has calls to databases,
transaction processing, and is built with batch jobs relying on JCL and system
utilities. Replacing the environment while retaining the integration and
reproducing the functionality is the hard part.

~~~
skissane
> COBOL doesn't do form handling. That would be CICS or IMS/DC software which
> the COBOL interfaces with

The COBOL 2002 standard includes form handling ("SCREEN SECTION"). However,
IBM COBOL implementations never included that, and so you are correct that on
IBM mainframes stuff like CICS and IMS/DC is used instead. Some COBOL
compilers on other platforms did implement "SCREEN SECTION", e.g. Micro Focus
COBOL on Windows/Unix, DEC COBOL on OpenVMS, Tandem NonStop COBOL, and COBOL
software developed for those platforms did use it. It is also true that non-
IBM mainframe COBOL is likely a minority of all COBOL software still in use.

~~~
lokedhs
GNU COBOL also implements it, and I have to admit that it's kind of fun to
play around with.

------
JustARandomGuy
We always have these articles about needing to learn COBOL, - I think we see
more of them since there’s more pressure on old systems such as unemployment
these days - but it’s important to note to anyone reading this that learning
COBOL is not going to lead to riches: I know several COBOL coders and while
they make a respectable amount, it’s nowhere near the amount they’d earn at a
FANG company.

Learn COBOL if you want - I learned COBOL early in my career and it’s very
interesting how different it is - but if you’re attempting to maximize salary
you’re better off spending time learning the bleeding edge tech.

~~~
raverbashing
I don't think any salary would be enough to compensate for the opportunity
cost of not working with a modern technology and the mental strain of working
with something so quirky and archaic

~~~
js8
It also has upsides. It might be archaic, but the code is mostly self-
contained, there are usually no layers of open source that might make behavior
difficult to understand. (And for problems with middleware you just call the
vendor.) Programs are typically designed to be algorithmically simple, the
complexity mostly comes from history and changing business requirements.

Mainframes are surprisingly transparent systems, if you learn where to look,
compared to Unixes. There are many logging and tracing facilities that run all
the time.

For these reasons, some people actually enjoy it more to work with these
systems.

~~~
Yetanfou
> there are usually no layers of open source that might make behavior
> difficult to understand

Ehhhh.... this in contrast to _closed_ systems where there are layers of
_closed source_ which lead to all sorts of unexpected behaviour without the
recourse of looking under the hood to find out what is going wrong. Closed
systems are _harder_ to debug than open source systems.

~~~
js8
In my experience, it depends on other factors than just whether the SW is open
source or not. Documentation helps, age of software helps (which means certain
stability with respect to change and less bugs), simple architecture helps.

I generally like open source, but I am skeptical when it is used as a tool to
save costs by companies. (Apache foundation projects are IMHO the worst
offenders.) In some sense, commercial software is the devil you know.

~~~
Yetanfou
> In some sense, commercial software is the devil you know.

No, _older, established projects or products_ are the devils you know, whether
they're free software or proprietary products. Take for example Debian Stable
which is, as its name implies, stable but seen as fairly stodgy and
unexciting. Stodgy and unexciting is what you want in a business environment.
The mere fact that there are far newer releases with loads of new features
(and bugs) does not mean that you need to use them, just wait for the next
stable release.

------
ketanmaheshwari
The article mentions that COBOL was an easy programming language to learn.
Personally, I disagree. As a beginner in a CS course, it was incredibly hard
to comprehend why a program needs so many sections and why the various lines
must start at a particular column. C seemed easy in comparison.

~~~
fortran77
The column requirements are a holdover from the days of punchcards, where
column 1 was reserved for JCL commands and some columns were reserved so cards
could be numbered and sorted by mechanical means.

~~~
kens
Many of IBM's early mainframes could only read 72 columns from a punch card,
which is why Fortran (and I assume COBOL) only used 72 columns. Specifically,
the IBM 704 was a 36-bit machine and read punch cards one row at a time,
filling two 36-bit words. There was a wiring panel that let you select _any_
72 columns to read, but obviously using the first 72 columns was most
sensible.

If you punched sequence numbers in the ignored columns 73-80, you could use an
electromechanical card sorter to put the cards back in order if you dropped
them.

~~~
fortran77
> if you dropped them.

Or if someone shuffled them (as we used to do in the computer room to people
who annoyed us.)

------
greencore
I think that the problem is not that coders don't want to learn COBOL but that
it's so niche language and you have almost no job mobility. If corporations
would offer contracts with extra huge severance packages then IMO there would
appear enough COBOL enthusiasts.

~~~
spaced-out
Seriously. Every time I see one of these COBOL articles posted here, I just
scroll through to see if there are salary stats, there never are.

If you want to convince people to learn COBOL, convince people you can have a
great career as a COBOL developer, or at least as a developer with COBOL in
your toolkit. I've yet to see anyone convincingly make that case.

------
acqq
I have written a pair of compilers (not COBOL) myself, so at one moment I've
thought about that possibility: "maybe I should spend a little time improving
my COBOL knowledge and move to that niche."

I wouldn't have problem working in archaic language, thought I. Or with non-
trivial codebases.

But then I've got another impression: the companies don't expect a new
candidate just to knew the language and work with old codebases. They expect
also the people to be able to work with ancient terminals, as in: no grep for
you. Even worse it's "no ASCII for you." I.e. not a single tool to which I'm
used I'd be able to use. Whatever I'm used to work with, I won't be able to
use.

That's where I became demotivated.

~~~
js8
I work on the mainframes. It's straightforward to download the code to modify
it locally and re-upload it. Then you can use all the tools you're comfortable
with. We are moving towards using Github as a main source repository, even for
mainframe code.

However, yes, knowledge of how to operate 3270 terminal is required. And it
has a form of grep, actually, as well as compare tools. EBCDIC is just another
encoding, not a huge problem.

~~~
Animats
EBCDIC. That's still around? Ugh.

COBOL apparently still has major problems with UNICODE. COBOL in IBM land can
only do UTF-16. Some IBM products are big-endian UTF-16, and some are little-
endian UTF-16. COBOL (PeopleSoft version) in Oracle land can do UTF-16 and,
sometimes, UTF-8 in programs for fields not stored in the database.

It's late for the language to be in that state.

------
protomyth
I figured that one reason COBOL and RPG IV continue to exist is that a
replacement language that can check all of the boxes hasn't been developed. It
is just not that cool a job to write a COBOL replacement like it is to write a
C replacement. Rust and Go need a bunch of libraries to do COBOL's work.
Frankly even with the libraries, both are too complicated to replace COBOL. It
just isn't a cool area like most Enterprise software.

------
epx
COBOL was like so many 4GLs: easier for starters and vanilla tasks, but makes
things increasingly difficult as you need to grow out.

~~~
KineticLensman
> COBOL was like so many 4GLs:

COBOL was one of the original 3GLs, and appeared in 1959. The concept of 4GL
wasn't even formalised until 20 years later in 1981 [0]

[0] [https://en.wikipedia.org/wiki/Fourth-
generation_programming_...](https://en.wikipedia.org/wiki/Fourth-
generation_programming_language)

~~~
epx
I said it was _like_ 4GLs. And perhaps the creator was ahead of her time? :)

------
praptak
The article focuses on technical skills and people who need to acquire them.
Which may be a problem but I don't think it is the root cause of the COBOL
problem as a whole.

There are organizations which dug themselves into the COBOL hole. What are
they doing to get people to learn the skills necessary to deal with the next
crisis?

~~~
pjmlp
Teaching them Visual Cobol or NetCobol, :)

[https://www.microfocus.com/en-us/products/visual-
cobol/overv...](https://www.microfocus.com/en-us/products/visual-
cobol/overview)

[https://www.fujitsu.com/global/products/software/developer-t...](https://www.fujitsu.com/global/products/software/developer-
tool/netcobol/index.html)

Who knows, that cool Kubernetes microservice deployed on Amazon might have
been written in Cobol,

[https://www.microfocus.com/media/success-
story/trasmediterra...](https://www.microfocus.com/media/success-
story/trasmediterranea-acciona_tcm6-210848.pdf)

------
booleandilemma
Just pay COBOL developers an obscene salary.

You'll have tons of eager applicants claiming to have years COBOL experience
at your door in no time.

~~~
zerr
Exactly, and in general - there is no shortage of programmers - there is a
shortage of programmers who are willing to work for 5-figure.

