As the Common Business Oriented Language, COBOL has a long and storied history. To this day it’s quite literally the financial bedrock for banks, businesses and financial institutions, running largely unnoticed by the world on mainframes and similar high-reliability computer systems. That said, as a domain-specific language targeting boring business things it doesn’t quite get the attention or hype as general purpose programming or scripting languages. Its main characteristic in the public eye appears be that it’s ‘boring’.
Despite this, COBOL is a very effective language for writing data transactions, report generating and related tasks. Due to its narrow focus on business applications, it gets one started with very little fuss, is highly self-documenting, while providing native support for decimal calculations, and a range of I/O access and database types, even with mere files. Since version 2002 COBOL underwent a number of modernizations, such as free-form code, object-oriented programming and more.
Without further ado, let’s fetch an open-source COBOL toolchain and run it through its paces with a light COBOL tutorial.
Spoiled For Choice
It used to be that if you wanted to tinker with COBOL, you pretty much had to either have a mainframe system with OS/360 or similar kicking around, or, starting in 1999, hurl yourself at setting up a mainframe system using the Hercules mainframe emulator. Things got a lot more hobbyist & student friendly in 2002 with the release of GnuCOBOL, formerly OpenCOBOL, which translates COBOL into C code before compiling it into a binary.
While serviceable, GnuCOBOL is not a compiler, and does not claim any level of standard adherence despite scoring quite high against the NIST test suite. Fortunately, The GNU Compiler Collection (GCC) just got updated with a brand-new COBOL frontend (gcobol) in the 15.1 release. The only negative is that for now it is Linux-only, but if your distribution of choice already has it in the repository, you can fetch it there easily. Same for Windows folk who have WSL set up, or who can use GnuCOBOL with MSYS2.
With either compiler installed, you are now ready to start writing COBOL. The best part of this is that we can completely skip talking about the Job Control Language (JCL), which is an eldritch horror that one would normally be exposed to on IBM OS/360 systems and kin. Instead we can just use GCC (or GnuCOBOL) any way we like, including calling it directly on the CLI, via a Makefile or integrated in an IDE if that’s your thing.
Hello COBOL
As is typical, we start with the ‘Hello World’ example as a first look at a COBOL application:
IDENTIFICATION DIVISION. PROGRAM-ID. hello-world. PROCEDURE DIVISION. DISPLAY "Hello, world!". STOP RUN.
Assuming we put this in a file called hello_world.cob, this can then be compiled with e.g. GnuCOBOL: cobc -x -free hello_world.cob.
The -x indicates that an executable binary is to be generated, and -free that the provided source uses free format code, meaning that we aren’t bound to specific column use or sequence numbers. We’re also free to use lowercase for all the verbs, but having it as uppercase can be easier to read.
From this small example we can see the most important elements, starting with the identification division with the program ID and optionally elements like the author name, etc. The program code is found in the procedure division, which here contains a single display verb that outputs the example string. Of note is the use of the period (.) as a statement terminator.
At the end of the application we indicate this with stop run., which terminates the application, even if called from a sub program.
Hello Data
As fun as a ‘hello world’ example is, it doesn’t give a lot of details about COBOL, other than that it’s quite succinct and uses plain English words rather than symbols. Things get more interesting when we start looking at the aspects which define this domain specific language, and which make it so relevant today.
Few languages support decimal (fixed point) calculations, for example. In this COBOL Basics project I captured a number of examples of this and related features. The main change is the addition of the data division following the identification division:
DATA DIVISION. WORKING-STORAGE SECTION. 01 A PIC 99V99 VALUE 10.11. 01 B PIC 99V99 VALUE 20.22. 01 C PIC 99V99 VALUE 00.00. 01 D PIC $ZZZZV99 VALUE 00.00. 01 ST PIC $*(5).99 VALUE 00.00. 01 CMP PIC S9(5)V99 USAGE COMP VALUE 04199.04. 01 NOW PIC 99/99/9(4) VALUE 04102034.
The data division is unsurprisingly where you define the data used by the program. All variables used are defined within this division, contained within the working-storage section. While seemingly overwhelming, it’s fairly easily explained, starting with the two digits in front of each variable name. This is the data level and is how COBOL structures data, with 01 being the highest (root) level, with up to 49 levels available to create hierarchical data.
This is followed by the variable name, up to 30 characters, and then the PICTURE (or PIC) clause. This specifies the type and size of an elementary data item. If we wish to define a decimal value, we can do so as two numeric characters (represented by 9) followed by an implied decimal point V, with two decimal numbers (99). As shorthand we can use e.g. S9(5) to indicate a signed value with 5 numeric characters. There a few more special characters, such as an asterisk which replaces leading zeroes and Z for zero suppressing.
The value clause does what it says on the tin: it assigns the value defined following it to the variable. There is however a gotcha here, as can be seen with the NOW variable that gets a value assigned, but due to the PIC format is turned into a formatted date (04/10/2034).
Within the procedure division these variables are subjected to addition (ADD A TO B GIVING C.), subtraction with rounding (SUBTRACT A FROM B GIVING C ROUNDED.), multiplication (MULTIPLY A BY CMP.) and division (DIVIDE CMP BY 20 GIVING ST.).
Finally, there are a few different internal formats, as defined by USAGE: these are computational (COMP) and display (the default). Here COMP stores the data as binary, with a variable number of bytes occupied, somewhat similar to char, short and int types in C. These internal formats are mostly useful to save space and to speed up calculations.
Hello Business
In a previous article I went over the reasons why a domain specific language like COBOL cannot be realistically replaced by a general language. In that same article I discussed the Hello Business project that I had written in COBOL as a way to gain some familiarity with the language. That particular project should be somewhat easy to follow with the information provided so far. New are mostly file I/O, loops, the use of perform and of course the Report Writer, which is probably best understood by reading the IBM Report Writer Programmer’s Manual (PDF).
Going over the entire code line by line would take a whole article by itself, so I will leave it as an exercise for the reader unless there is somehow a strong demand by our esteemed readers for additional COBOL tutorial articles.
Suffice it to say that there is a lot more functionality in COBOL beyond these basics. The IBM ILE COBOL reference (PDF), the IBM Mainframer COBOL tutorial, the Wikipedia entry and others give a pretty good overview of many of these features, which includes object-oriented COBOL, database access, heap allocation, interaction with other languages and so on.
Despite being only a novice COBOL programmer at this point, I have found this DSL to be very easy to pick up once I understood some of the oddities about the syntax, such as the use of data levels and the PIC formats. It is my hope that with this article I was able to share some of the knowledge and experiences I gained over the past weeks during my COBOL crash course, and maybe inspire others to also give it a shot. Let us know if you do!
Let me offer a COBOL memory: I worked in a COBOL shop eons ago. One day a salesman came in to pitch a product called, if memory serves, the CAPEX Optimizer. He set up in a conference room with an overhead projector and launched into his presentation. Every single time his script called for him to say “COBOL”, he mispronounced it “cobalt”. Lots of eye-rolling around the table, but he never caught on.
Love the illustration. That’s an IBM 704 front panel, a vacuum tube machine popular in the 1950’s. It was the quintessential mainframe of its era.
Honestly would love to learn more. It’s like watching wizards share meaning of the old runes.
“It used to be that if you wanted to tinker with COBOL, you pretty much had to either have a mainframe system with OS/360 or similar kicking around,” – Not true, there have been PC versions of COBOL going back to the 1970s. I believe Microsoft even produced some. More recently MicroFocus has ruled that market, including one that ran on top of the .NET framework.
Plus pretty much every business minicomputer/midrange had a COBOL implementation as well.
Marketing and business folks talk about “pain points”. The huge honker of an easily checked mistake that you mention was the Disappointment Point of this article.
Jim, right you are. I worked with a TRS 80 with 64k RAM to develop COBOL code. The compiler was stored on a floppy disk that was inserted prior to compiling. 1983-1986. RIP Radio Shack lol.
I like the illustration too. ‘Real’ computers must have switches and lights. Just something about that, that appeals to me :) . While modern computers do the job, they just seem coldly ‘utilitarian’. Hard to put into words…
Thanks for the article. Dabbling in Cobol is interesting. But that is about as far as I will go. With Rust, C/C++, Pascal, Python, Perl, assembly (ARM/RISC-V/x86_64) at my finger tips … Well, it is just not practical to add to the brain another language to be ‘proficient’ in that I’ll never use for anything.
Now you’ve got me questioning my habit of reading strangers on the internet listing languages that they’ll never use; can it be argued that it advances or benefits me in any way?
Fifty years ago, had the warning that COBOL was an obsolete language that was to be replaced immediately by ( insert your favorite other language here).
Still waiting, retired five years ago. YMMV
Fifty years ago, had the warning that COBOL was an obsolete language that was to be replaced immediately by ( insert your favorite other language here).
Still waiting, retired five years ago. YMMV
Took a three week course when I started as a COBOL programmer at the start of the 80’s. It could probably have been done in one. I found coding with a pencil into gridded paper dull, and once I had been in the computer room and seen the 1900 serise ICL mainframe running GEORGE 3, that was where I wanted to be. Writing early database financial information services helped keep me interested for a few years but the move into tech support couldn’t come quick enough. I still have reflex twitches when I see a line of any code that doesn’t end with a period :-)
Wow! When I was studying computing, we learned on the 1904a, also with George3! Among other things, we learned PLAN, and competed with other students for time on the MOPs. Sometimes we had to settle for an ASR33, but as time wore on we got to fight over visual terminals.
WE COMERR… (IYKYK)
IIRC that Fujitzu(sp?) has a pretty slick version of COBOL quite some time back?
Nice overview. After a 46 year career using dozens of computer languages, I’ve never understood the particular vitriol that seems to be reserved for COBOL. I learned it with an IBM self-paced course in a couple weeks as jumped right into my job. Sure, it has some problems and limitations, but it’s a workhorse language for a reason
In 1988 i learned Cobol as my second prog. language after MS-Basic.
I worked for a company in the banking business for many years while programming Cobol.
In 1994 all things turned,
“C” was introduced, the ugly data menagement turned into SQL and the other next years we ported all the business to “C”.
From that time Cobol was declared a a obsolete language.
Slight alteration to your timeline. We used Cobol on dos 2nd year of university 1989.
Oooooh….
I remember JCL.
We had an IBM mainframe at Avondale shipyards when I went to work there in 1980.
There was a guy named Harold Luke that was the JCL/Fortran wizard.
I learned a little JCL, but it’s long gone.
1975 -1976, just out of the Navy as an IC-3. Didn’t know whether I wanted to go software or hardware, took a few classes in software programming, COBOL, FORTRAN, RPG and RPG-II. My first COBOL program punched on IBM keypunch, had it run on a IBM 360/30…end result 327 computer pages of errors…I left out a ( ; ). Later after all my classes which I got A’s in; I decided to go hardware.
This is great, not to knock the article at all, but what EVERY introduction to COBOL lacks is exposure to what real COBOL codebases ACTUALLY look like.
That’s where the problem is.
You can teach yourself COBOL in a vacuum really easily. You cannot teach yourself to understand legacy COBOL code without exposure to said legacy COBOL code and the context it was created in. Nothing can prepare you for the sprawl and the crappy documentation and idiosyncrasies of dead people.
I did an introduction to programing in the 1980s maybe the end of the 1970s and it was with the local town councils NCR IMOS Cobol mainframe… To say it was illuminating and awful is an understatement.
What makes me think what a world we live in today, they let a room full of teenagers on the town councils mainframe (the only computer in town) and nobody thought anything of it.
The language makes a lot of sense if you understand its historical context. The kinds of business processes that it automated were the sort that were either done manually — processing documents from “IN” to “OUT” trays (as seen only in cartoons these days) or using a card tabulator or sorter where one or more input streams of individual data records would be combined to form a new stream of data or tabulated to get some overall result. The language syntax is explained by the limitations of punched card data entry where it was common practice to start fields of a program statement on specific character column numbers. These are likely alien concepts to people brought up on interactive computing via a GUI.
I remember working with COBOL on the Burroughs Medium systems. The instruction set of the system was designed for COBOL. From the Wikipedia entry – They operated directly on COBOL-68’s primary decimal data types: strings of up to 100 digits, with one EBCDIC or ASCII digit character or two 4-bit binary-coded decimal BCD digits per byte.
https://en.wikipedia.org/wiki/Burroughs_Medium_Systems
That is how we did it in 90ies. After i developed a tool that reads working section and help us create and design forms, my chief showed me the screens.exe that was already exist and did the job :) I remember we used display cards memory to speed up selection list forms’ scroll jobs.
Impressive, that COBOL code looks like gibberish. Its like reading raw disk sectors containing some sort of old timey database.
That’s exactly what it is, so I suppose “gibberish” here means “intuitively readable,” which it is, and was designed to be.. Don’t get me wrong, it’s a horrible language, but it’s not difficult, and some of us find bf fun. Writing COBOL is like a mild version of that, except you can read it later.
Great introduction to COBOL! I appreciate how you balanced historical context with practical steps for getting started today. It’s encouraging to see how accessible COBOL has become for hobbyists, especially with tools like GnuCOBOL and GCC’s new frontend. Looking forward to more deep dives—maybe even that full code walkthrough if there’s enough interest.
Cobol is extremely wordy.
I always hated typing:
MOVE CORRESPONDING
Not my preferred language.
I know people will mention using it for reports or maybe user terminals. But it was really better for backend business tasks.
Heavy report coders were much better off using RPG. Especially for simpler reports.
Unfortunately there was a ton of legacy code written before RPG was adopted