I Took a COBOL Course and It Wasn't The Worst

COBOL is in the news again. Millions of people are filing unemployment claims nearly all at once, and the systems to process them are failing. Why? They need to scale to unprecedented levels, they’re written in COBOL, and… we don’t have enough COBOL programmers.

Here’s a look at the increase in searches for “COBOL programmers”:

Most COBOL programmers are retired. The pipeline of new COBOL programmers is nearly nonexistent. Many are coming out of retirement just to help.

This piqued my curiosity. I know nothing about COBOL, other than it’s old, still used a lot, and it was created by one of my heroes, Admiral Grace Hopper. I looked to see if Pluralsight had a course about it, and they do. It's called Getting Started with Mainframe COBOL.

Why Did I Take a COBOL Course?

So after reading about this problem I started thinking about COBOL again and got curious. Do I want to get a job as a COBOL programmer? Am I going to use this? No. As much as I love to roll up my sleeves and help in a crisis, I love my job and where I’m at. I don’t want to be a COBOL programmer. I’m just curious. I had to know how this decades-old language really works.

So I took the course and found out. Here’s what I learned.

How COBOL Programs Work

As I started to dig in, I immediately started hearing terms and acronyms I am not familiar with. This must be how a non-technical person feels when they’re trying to understand new technology. It’s an eye-opener. There’s a big COBOL world that exists, and I am unaware of it. I forged on.

COBOL programs are text (OK, that I can relate to) and they are divided into four main divisions:

• Identification Division
• Environment Division
• Data Division
• Procedure Division

As a seasoned developer, I can probably assume what most of these things are, but I kept going to see what I’d learn. My first impression was: this is a great way to organize applications. We do this in some form with many applications, but these hard fast rules for organization? I like it.

Identification Division

This provides identifying information, such as the name of the program who wrote it, and the date they compiled it. We see things like this in comments and package files these days.

Environment Division

This area tells what kind of system it’s being built on, what compiler is being used, and similar information. It’s not declarative but gives a programmer a general idea of the environment to build it in.

Data Division

This is for defining file fields. What type of data will come in? How is it defined? This can be internal fields such as accumulators, flags, and counters, or external fields such as parameters passed to your program.

Procedure Division

This is where the action happens. Think statements (sentences in COBOL), methods, computations, all the “meat” of the program lives here. This is the largest division of a COBOL program.

This kind of organization is great. It makes sense. We have this in nearly every language we develop with today. You punch in text that’s compiled to an executable run by the computer. That’s where the similarities end.

How Is COBOL Used?

COBOL reads files, performs actions on the data, and creates reports, or stores the new data. It’s suited for large-scale transaction processing. Think about something like calculating sales numbers for 5 million transactions. It’s primarily used on mainframe computers for finance and administrative systems.

According to this survey, 25,757 companies use COBOL. More than half of the companies I’ve worked for in my career used it somewhere. It’s out there everywhere, quietly processing our transactions every day.

Why Is It Still Around?

My guess is: because it works. Folks love to make jokes about COBOL, but this is a language that strives for reliability. It’s happy when you feed it large amounts of data. It’s used to process millions of records if needed, and “just works” day after day.

It’s primarily used in finance and government because organizations invested a lot of time and money to build COBOL systems, and these applications continue to chug away and do their job decades later. COBOL has a focus on performance and backward compatibility like no other.

If it isn’t broke, don’t fix it. The biggest weakness of COBOL seems to be the number of people who know it, not the language itself.

Similarities to Modern Development

You write code in text to .SOURCE file, and that gets compiled into a .LOADLIB file. Then those files are run by .JCL files. There are things like compilers and linkers and other stuff that seems familiar.

There are a few other aspects of COBOL that will be familiar to modern developers:

Output for Debugging - COBOL has error codes and other output. You can pipe them to SYSOUT, or a file. You can make it verbose to see what’s happening for debugging purposes, like any other language.

Reusable code- COBOL has functions, which is crucial for abstracting things, and ways of creating reusable code in COBOL. It’s even object-oriented if that’s your thing. You can build libraries to reuse.

Types are important - Type definition, conversions, and all those other headaches are present in COBOL. Types are important, but data formatting is even more important. You really have to get this right in COBOL.

Naming is important - You have a lot of freedom when naming things in COBOL, and how you do it is important. There seems to be an emphasis on the idea that “this program will grow large and be maintained for decades”, which is something you don’t think about as much when writing an Angular app.

The period is your semicolon - In COBOL, everything, and I mean everything, is terminated with a period. This is the idea of “Sentences” in COBOL. The language strives to be as humanly readable as possible.

COBOL has familiar control structures - Not surprisingly, you have many loops, if statements, and other control structures you recognize from whatever programming language you’re using today.

I found jumping into COBOL, it’s easy to understand the basics of how to get rolling, based on my experience with other languages. You can get a general idea of how it works, but it’s not completely foreign. Until you start working with the code.

Differences from Modern Development

Once you get started working with COBOL, you’ll notice some big differences between this and casual JavaScript coding.

You need a mainframe - To truly develop COBOL, you need a mainframe. I’ve found some simulators online, and GnuCOBOL is pretty cool, but the real deal lives on mainframes, so you’ll need access to one for true COBOL development.

Human readable - Everything is very human-readable, though the code is in all caps, so it’s yelling. Statements are called “sentences” that are punctuated by a period. The period is small, so it’s tough to find where you forgot to add it.

Rigid Syntax - COBOL earned its reputation for rigid syntax. Spaces at the beginning and end of every line (like bookends) and every single space and character matters. You need an eagle eye for coding with this language.

Wild constraints - There are constraints in place in 2020 that shouldn’t exist, but COBOL is dedicated to backward compatibility. A line of COBOL code is always 80 characters (unless it isn’t), and reports are 132 characters wide. Why? Because of punch cards, and old school impact line printers. Yes, really.

Resource stinginess is built in - You can really see how they designed the language around conserving resources. Memory, hard drive space, and CPU cycles are scarce so use them wisely. It’s easy for modern developers to forget how expensive and precious these things once were (and we should treat it that way now).

You must be very explicit - There isn’t much “loosey goosey” programming happening in COBOL, it won’t allow it. You have to intentional in everything you do. It’s very unforgiving, and that’s a good thing.

Jobs are a big focus of the language - It’s clear that COBOL is modeled around doing “jobs”. The programs are not real-time interactive programs like many applications, they’re designed to run at specified times, and the code is run from top to bottom. It’s meant to read in data, do things with that data, then spit it out.

What I Got out of This Course

After taking this course, I developed a respect for the language. COBOL gets a bad rap mostly because of its age and the Y2K bug (which wasn’t the fault of COBOL), but it’s still around for a reason: it was designed to be rock solid from the start. It’s not without its faults, but nobody can argue the durability of a system that runs for decades.

I feel comfortable enough with COBOL to have a general understanding of how it works. I wouldn’t hire me as a COBOL programmer, but I’m confident this course would put me on that path if I so desired. The author did a fantastic job with explaining the concepts, being funny/not boring, and explaining best practices and pitfalls very well.

If you’re a developer in 2020, you could learn a lot from this course. You can learn a few principles (that I made up myself) that seem to be prevalent in the world of COBOL:

• Preserve your resources - memory, disk space, and CPU cycles are not free. Conserve them as much as possible with what you build.
  
• Be explicit in everything you do - Take the time to figure out what you need and then declare it. Think arrays and structs instead of lists and generics. Performance comes from knowing exactly what you need and when.
  
• Write code as if it will live for decades - For COBOL programmers, it’s true. Think ahead and act as if your code will live on for years. How should you write it so it can be maintained further down the line?
  
• Avoid breaking changes - Modern developers love reinventing the wheel. We also like introducing breaking changes and telling people to upgrade if they don’t like it. COBOL takes the approach to only break things when there is no other option. We need a little more of that in 2020.

You should take Getting Started with Mainframe COBOL. You’d be surprised what you’ll learn. If you do, let me know what you think of it! I’d love to chat about it.