On COBOL

https://www.oreilly.com/radar/on-cobol/

by MindGods • 6 years ago

52 52 6 years ago

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.

pjmlp10• 6 years ago

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.

kyberias2• 6 years ago

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

fortran772• 6 years ago

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• 6 years ago

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.

praptak3• 6 years ago

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?

pjmlp10• 6 years ago

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

dwheeler• 6 years ago

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

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

epx2• 6 years ago

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

KineticLensman• 6 years ago

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

epx2• 6 years ago

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

mercantile• 6 years ago

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.

Yetanfou3• 6 years ago

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.

Smoosh2• 6 years ago

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.

skissane5• 6 years ago

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.

lokedhs2• 6 years ago

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

greencore• 6 years ago

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-out2• 6 years ago

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.

praptak3• 6 years ago

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.

JustARandomGuy• 6 years ago

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• 6 years ago

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

js83• 6 years ago

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.

Smoosh2• 6 years ago

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

spaced-out2• 6 years ago

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.

acqq• 6 years ago

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.

js83• 6 years ago

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• 6 years ago

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.

protomyth4• 6 years ago

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.

booleandilemma• 6 years ago

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• 6 years ago

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

On COBOL

Related Stories