On COBOL | Hacker News Reader

On COBOL

oreilly.com

52 pointsMindGods52 comments

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

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.

It helps to understand COBOL in the context of its environment: punchcards containing a single line of code, hierarchical (e.g. IMS) and network (e.g. IDMS) databases, the intended application being business data batch processing on mainframes, etc. In this context those field and record specifiers (etc.) make more sense.

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.

> 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.

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

It's actually not that complicated. It's just different and, coming from traditional languages, strange.

Some technical mistakes in your post was already raised by another reply, and I just want to point out how the levels actually work. I've played around with COBOL on and off out of casual interest, but when the Oreilly COBOL book became available to me recently I decided to read it just for fun.

As it turns out, COBOL mixes the concept of variables and report definitions. To paraphrase an example from the book[1], which I can recommend:

    01 date-of-birth.
      02 year.
        03 century pic 99.
        03 year-in-century pic 99.
      02 filler pic x value "-".
      02 month pic 99.
      02 filler pic x value "-".
      02 day pic 99.

With that definition, you can read and write values to and from each individual field, but also access the higher level ones as a combined field. For example, if I assign a full ISO 8601 date to the variable date-of-birth, like so:

    move "2010-01-02" to date-of-birth

I can then read the year by simply reading the corresponding variable:

    display "year is ", year

It all becomes much more clear once one realises that variable definitions in COBOL are conceptually field definitions for reports and fixed column storage formats. If the task at hand matches the way COBOL thinks of data, things are pretty simple. Once you want to move outside that realm things becomes harder.

My understanding is that in the mainframe world, COBOL programs are parts of much larger workflows, all coordinated by JCL scripts. Since all data is already in fixed column form, typing together these COBOL programs is similar to how you build pipes out of different programs when you write shellscripts in Unix.

[1] https://learning.oreilly.com/library/view/beginning-cobol-fo...

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.

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

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.

> 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.

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.

> 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.

> something so quirky and archaic Try APL. It's the 1960s equivalent of 05AB1E.

>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.

This goes along really great with the closing paragraph of the article:

>That’s the new generation of COBOL programmers that we need: people to do the tedious, unglamorous work of re-inventing, re-engineering, and automating government applications, business applications, and much more. Reimagining these processes is creative work, but it requires a different kind of creativity from implementing a new website.

Gee, why is it that people are trying to hard to get into FAANGs rather than learning COBOL.

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.

When COBOL was invented C did not even exist, it only came to be about 10 years later.

The alternatives were Assembly, FORTRAN and ALGOL.

But they have coexisted at the same time haven't they?

They have coexisted since early 70s, back when C was invented.

However where COBOL rules is on mainframes, which after Assembly have always used PL/I derived systems programming languages (like Unisys, IBM i and z/OS), so on those systems C is just another guest language and hardly anyone cares to use it beyond porting software to their POSIX runtimes.

Right, that's why I don't understand why you had to bring up the fact that C was invented later. OP didn't claim anything related to that.

Because COBOL was seen as productive in the context of 1950's computing environments.

Unlike Fortran, COBOL really hasn't evolved in the C dominated world. Although C is really dominant on the platforms COBOL lives on.

What?!?

Cobol has had its last revision in 2014, supports modules, OOP, and even has .NET and JVM backends.

MicroFocus and Fujistsu also have frameworks for cloud deployments and writing microservices in Cobol.

Almost no one cares about C on mainframes beyond porting some POSIX stuff, or running Aix/Linux on an hypervisor.

That's basically it, no one cares about C on the mainframe so COBOL doesn't deal with the C competition and C flaws that fuel Go and Rust. COBOL itself has advanced but it doesn't have the same competition.

They don't care about C because mainframes always had better alternatives for systems programming, via PL/S, PL.8 and NEWP, as the three major surviving ones.

Even BLISS and Mesa were better than C.

If I remember correctly OpenVMS was programmed in something else also.

It would have been interesting if one of the PC operating systems had decided to use one of those languages.

So, no C, no interest in 'I need a C replacement language', enterprise software is boring, so no COBOL replacement. Plus, I know of at least one vendor who did develop something but it is kept in-house.

I did expect someone to develop yet another REXX to address this need.

> Almost no one cares about C on mainframes beyond porting some POSIX stuff, or running Aix/Linux on an hypervisor.

I think, with Metal C, that's less true than it used to be.

My understanding is that, for brand new z/OS components (e.g. Zowe, z/OSMF), IBM prefers Metal C to PL/X. It is also seeing increasing use by mainframe ISVs as a replacement for assembly and PL/X.

IBM uses mostly C++ alongside PL/S, Metal C is a niche solution, most users are supposed to target the language environments.

For low level stuff, you can’t use the language environment. Assembler, PL/X and Metal C work fine without the language environment, C++ requires it.

And unless one is an IBM employee on IBM i team or driver writer for IBM i, there isn't really a sound reason to use it, hence niche.

Metal C is for z/OS, not IBM i.

ISVs definitely use it, not just IBM. Most z/OS user exits cannot use language environment, they must use either Metal C, assembly or PL/X. (And, outside of IBM, PL/X is only an option for those few companies who have bought PL/X licenses, which apparently IBM doesn’t even sell anymore.)

Also, historically there has been a big culture at z/OS sites of writing site-specific user exits in assembly. Less of a need for it nowadays given features in newer z/OS versions and ISV solutions, but some folks still do it. And Metal C is the only alternative to assembly that customers have.

For a real world example of where it is used, I used to work with a product that used RACF user exits to send security change notifications over the network to a Java app running on a Unix system, for auditing, scheduled access certification, etc. (The user exit in question was written in HLASM not Metal C, but if you were building the same thing from scratch today you’d quite possibly choose Metal C over HLASM. You can’t write a RACF user exit in C++ because that needs language environment and language environment use is not allowed in RACF user exits.)

Yes, I mix IBM i and z/OS all the time, thanks for the correction.

However I would say that is exactly the example of a niche use case.

Vendors who write system level software (security, backup, operations, management, batch scheduling, middleware, databases, transaction monitors, etc) do a lot of that you are classifying as “niche”, but for which Metal C is one of the few available options.

Application level stuff, nobody should use Metal C for that. Use Language Environment C/C++. But at application level, C and C++ are not very popular languages for z/OS. COBOL and Java are.

On IBM i, IBM used C++ heavily as a system programming language, especially as a replacement for PL/MP. By contrast, C++ has always been relatively niche on z/OS.

Fair enough, thanks for the overview.

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.

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.

> if you dropped them.

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

My professor told us of a technique he used to recover from stack drops. Draw a pattern with a felt tip pen across the side of the stack (on the edges of the cards).

This way a quick glance can tell you if the stack is out of order and it's also faster to sort manually.

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.

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.

Also it's not like you are fighting Covid or the global climate change. Helping solve "the COBOL crisis" will just let some corporations save some money.

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.

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.

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.

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.

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

> 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_...

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

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?

Teaching them Visual Cobol or NetCobol, :)

https://www.microfocus.com/en-us/products/visual-cobol/overv...

https://www.fujitsu.com/global/products/software/developer-t...

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

https://www.microfocus.com/media/success-story/trasmediterra...

The Linux Foundation's "Open Mainframe Project" has a free COBOL training course. More info here:

https://www.openmainframeproject.org/projects/coboltrainingc...

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.

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

Reply on news.ycombinator.com