The language that Refuses to Die

Tutorials – COBOL

Article from Issue 204/2017
Author(s):

Despite being more than half a century old, COBOL is still in use. Explore this fascinating old-school language and see how it ticks.

New programming languages pop up all the time. In recent years, there's been plenty of hype around Rust, Go, Swift, Clojure, and many others – and often for good reason. These languages have their own plus points and useful features, and many of them are maturing well. Despite hyperbolic claims from certain overzealous fans, however, none of these languages are going to replace C, C++, or Java completely any time soon. Sure, those languages are old and have their limitations, but they're extremely well established, and rewriting large codebases in the current hot language du jour is a mammoth task.

Although C dates back to the early 1970s, there's an even older language that's still in use – albeit to a much lesser extent. COBOL, the common business-oriented language, was created in 1959 by the US Department of Defense (Figure 1) as a portable language that could be used to process data across many different machines and architectures. The language was standardized a few years later, although there are many different dialects. The most recent update to the language specification was COBOL 2014.

Figure 1: US Navy Rear Admiral Grace Hopper had a huge influence on modern computing and helped create COBOL.

Why is such an ancient language still in use today? COBOL doesn't look pretty, but it's quite easy for mere mortals to write (as you'll see in a moment) and is especially suited for data and transaction processing. Indeed, many banks still use COBOL extensively – not on 1960s or 1970s hardware, of course, but on modern mainframes that are purposely built for the task. IBM still makes plenty of bucks selling big-iron hardware running COBOL [1] (Figure 2).

Figure 2: Many companies are still using thousands (or even millions) of lines of COBOL, often on big-iron mainframes.
Figure 3: Have a search on Amazon, and you can see that books are still being written about COBOL, such as this one from Apress in 2014!

Sure, some companies are slowly migrating from COBOL to other languages, but recent surveys suggest many billions of lines of COBOL are still being used in production. COBOL coders can earn good money, too; even though jobs based around this language aren't widespread, experts can be sure of long-term work prospects maintaining old (but functioning) codebases. (See the "Does COBOL Have a Future" box.)

Does COBOL Have a Future?

The answer is yes. Despite being an ancient language, COBOL hasn't stayed completely still (Figure 4). Developers are working on new features and syntax for the language, and we expect to see some more standards updates over the next 10 or 20 years. That sounds like a very long time, indeed, but bear in mind that lots of COBOL code written in the 1970s and 1980s is still being used in production today.

Large organizations are pretty conservative when it comes to major changes, and while devices and interfaces change rapidly (think of the big switch to mobile devices and web-based interfaces in recent years), COBOL will still be grinding away in the background, churning through data for many years to come. I think there's something quite reassuring about that in this hectic world.

In this tutorial, I'll explore some of the features of COBOL and show you how the language works. Even if you never intend to write another line of COBOL again, it's well worth exploring the language to see how it influenced other languages. Plus, you get extra geek bragging rights and can tell those darn kids with their fancy new meme languages to get off your lawn. Let's go!

Installing COBOL

I mentioned IBM COBOL before, and if you look around the net for other commercial COBOL implementations, you may become light headed when you see the prices. Usually the COBOL vendors don't even list them, preferring you to contact them for a sales quote, but they're not cheap: You're looking at minimum $500 for a single developer license and many thousands of dollars for enterprise-level solutions. That's not especially surprising, given that these tools are targeted at banks and other large organizations, but it's not ideal for us.

Fortunately, there's an open source implementation: GnuCOBOL (formerly known as OpenCOBOL) [2]. In some distros, it's still provided under the name OpenCOBOL, so in Debian and Ubuntu systems you can get it with this command in a terminal window:

sudo apt-get install open-cobol

For other distros, open your package manager and search for COBOL, and you should find it. Once installed, it's time to test it! To write your very first COBOL program, create a file called test.cbl in a plain text editor (Figure 4) with the following content:

IDENTIFICATION DIVISION.
PROGRAM-ID. TEST-PROGRAM.
PROCEDURE DIVISION.
    DISPLAY 'Ciao!'.
    STOP RUN.
Figure 4: The Vim editor has a syntax highlighting scheme for COBOL code to make it easier on the eyes.

Not the prettiest language ever, is it? Actually, you can switch the uppercase characters here to lowercase to make it slightly friendlier to the eyes; however, I'm sticking with the traditional formatting, as you'll see in code written decades ago.

This program doesn't need much explanation; you can see that it prints "Ciao!" on the screen and then ends. COBOL programs are split into divisions, as you can see here, with the IDENTIFICATION division providing some information about the program, and the PROCEDURE division containing the code itself. You'll also note that each line ends with a full stop (period). This looks rather bizarre, and obviously this approach wasn't adopted by other programming languages, but you can see how the language designers thought it'd make the code look more like natural human language.

Compile your test.cbl file into an executable binary like so:

cobc -free -x -o test test.cbl

The -free flag tells GnuCOBOL to be more lenient when parsing code (rather than requiring extremely precise formatting), and -x tells GnuCOBOL to generate an executable file. Afterward, you have a binary called test that you can execute with:

./test

There you have it! Your COBOL coding career has begun.

Working with Data

Next, you can create a slightly more complex program, with some variables. In COBOL, you have to declare variables in the DATA division and be very specific about their size and capabilities (e.g., Listing 1).

Listing 1

COBOL Program with Variables

 

Think about what happens here – if you've done some programming before, you've probably guessed that it prints Ciao followed by the number 123. Well, that's almost right, but there's quite a bit going on here.

First of all, the DATA division sets up a subsection for "working storage" – that is, for the variables. You define two of these, starting each time with the level number – in both cases 01. You can use levels to split up and organize data, but I won't go into that now. This program is pretty simple, so you can just use the top level for your variables.

Next, you provide names for the variables: WS-NUM1 and WS-NAME1. You can use other names here, providing they don't clash with existing COBOL keywords, but it's common practice to precede them with WS-. Next, the PIC provides a picture of the storage required for the variable. In the first case, 9(3) means numeric data of a maximum of three bytes, and in the second variable, X(10), means alphanumeric data with a maximum of 10 bytes (i.e., a string variable, effectively). Additionally, the value for the second variable is set immediately.

Yes, it may look ugly and fiddly – especially when compared with more modern programming languages – but bear in mind the extremely limited specifications of computers running COBOL back in the 1960s and 1970s. Every byte was important, and it was essential to be very specific about the type of data that could be stored to avoid problems later on. The PROCEDURE division displays the contents of WS-NAME1 and then sets the value of WS-NUM1 and displays it as well.

So far so good – now for a look at input, paragraphs, and loops. In COBOL, paragraphs let you split your code into smaller chunks, much like functions or subroutines in other languages. These paragraphs live in the PROCEDURE division; Listing 2 shows an example of these paragraphs in use in a program that gets the user's name and then prints a greeting message 10 times.

Listing 2

COBOL Example Using Paragraphs

 

In Listing 2, the DATA division contains two variables, as in the previous example. Then, the PROCEDURE division begins with a new paragraph called A-PARA. Using COBOL's ACCEPT keyword, the program gets a string from the user and stores it in the WS-NAME1 variable.

Then some magic starts a loop by telling COBOL to PERFORM (execute) the code in the B-PARA paragraph underneath, again and again, until the WS-NUM1 variable contains 10. After that, the program stops. Now look in B-PARA: You can see that it prints Hello followed by the contents of the string variable, and then it increments the WS-NUM1 variable by one. Once execution of B-PARA is complete, execution continues back in the PERFORM line in the previous paragraph, so B-PARA is executed 10 times.

Strings, Conditionals, and Modules

As you'd expect from a language designed for data processing, COBOL has plenty of ways to handle strings, and as you've probably come to expect from the previous code examples, they're not always the prettiest – but they work! So now I'll look at how to count the number of specific characters in a string and then use conditionals to print a message. This program asks the user to input some text and then counts the number of "a" characters in the string. If there are no characters, it prints one message – but if some "a" characters can be found, it displays the exact count (Listing 3).

Listing 3

Counting Characters

 

In this code example, I create a numeric and a string variable in the DATA division, as before. The PROCEDURE part uses ACCEPT to get the user to input some text and then uses the INSPECT command to analyze the string. You can do various things with INSPECT; in this case, TALLYING counts all instances of the letter "a" that are stored in the variable. Then, this number is placed into the WS-NUM1 variable.

Next up is a conditional block. If you've ever programmed in BASIC, this structure will be instantly recognizable to you – the IF does a comparison, and if that's true, the code after THEN is executed. However, if the comparison doesn't match, the ELSE code is executed instead. In this program, if WS-NUM1 contains zero, it prints one string; if it contains a larger number, however, it prints something different. Note that these IF blocks have to be terminated with an END-IF statement.

Finally, I'll take a look at modules. As in most programming languages, when you're working on a large project in COBOL, the code will be split up into many different files, and you don't want to recompile the whole caboodle every single time you make a change – just the file that has been changed. To see this in action, first create a file named test.cbl (Listing 4), and then a file called extra.cbl (Listing 5).

Listing 4

test.cbl

 

Listing 5

extra.cbl

 

First, compile extra.cbl:

cobc -free -m extra.cbl

Note the -m flag here, which tells the COBOL compiler that you want this file to be turned into a module, rather than a standalone executable. Second, compile test.cbl (Listing 4) as you usually would. Finally, run test; you'll see from the output that WS-NUM1 is initially set to 10, but after the program has jumped into the EXTRA module, it is set to 20. If you have problems running this code, try the following beforehand:

EXPORT COB_LIBRARY_PATH=<path to where your COBOL source files are>

How does this program work? Most of test.cbl is easy to understand by now, but the magic takes place in the CALL line. This hands over control to the compiled EXTRA module. Note the LINKAGE SECTION line in the DATA division of extra.cbl. This line tells COBOL that you don't want to create brand new variables here, but instead use the ones from the calling program – that is, the ones defined in test.cbl.

In the PROCEDURE division, set the value of WS-NUM1 to 20, instead of 10 as it was originally, and you'll also see that the module ends with EXIT PROGRAM rather than STOP RUN, because the latter halts execution completely. You don't want to do that, of course, you just want to hand control back to the calling program!

So those are the basics of COBOL. There's much more to the language, of course, so check out the GnuCOBOL Guides page [3] for more reading material. Oh, and if you end up getting a lucrative job in a bank, making megabucks from maintaining old COBOL codebases, don't forget about the tutorial that got you started in this career. At least send us a beer. Thanks.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Welcome

    Of all the strange news this month, the one item that really caught my eye was the announcement of IBM's COBOL for Linux 1.1 compiler. I guess most of us are aware that millions of lines of business software around the world are still written in COBOL, and for that reason, old-school COBOL programmers still have work. But think about this for a minute: COBOL has existed for 62 years, the x86 architecture has been around for 43 years, and Linux has been with us for 30 years.

  • Ode to Machine Architecture
  • A little knowledge is dangerous
  • The sys admin's daily grind: Adminer

    Sys admin columnist Charly freely admits that he doesn't like SQL and phpMyAdmin any more than he does COBOL. Instead, meet his new best friend; the slim, attractive database tool known as Adminer.

  • Introduction

    This month in Linux Voice. 

comments powered by Disqus

Direct Download

Read full article as PDF:

Price $2.95

News