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!
Nice illustration for the Title!
Thanks Joe Kim!
(now I’ll read the article…)
Right? :)
I also got a small remark before reading the article. From what I’ve learned about COBOL and just reading snippets here and there, never trying to learn it for real (wonder why), the title suggested me a careful mother kissing the young IT boy’s head (that’s the “gentle” part) and wishing him success, then dropping 20 pounds of printed documentation over the same young IT boy (that would be the “introduction to COBOL”). If he’s lucky, the papers are still in the boxes after the echoes of the impact are gone. Now back to the article.
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.
Being a COBOL programmer is like being a mob lawyer – once you take that first job, there’s no way to go back to your old life. Be very, very certain this is what you want to do before you close that door behind you.
“Be very, very certain this is what you want to do before you close that door behind you.” Of course there just might be some fringe benefits as one of the few experts in the field… Like flying your own jet to different clients and such, or that yacht you vacation on… Not for me though. Past the ‘get a new career’ stage in life.
There is life after being a COBOL programmer (I learned that back in 1985 whilst in the USAF): moved on and learned to program in C/C++ in the 90’s… And became a computer engineer 10 years later… Now getting an MBA to set up my retirement…
After all that work, your going to take the MBA lobotomy?
Strange thinking…but MBA student.
…And COBOL programmer…
Do you now, or have you ever,worked for EDS/HP enterprise, TaTa or Infosys?
One of the few jobs where ageism shouldn’t be a problem.
I’ve always heard how COBOL coders can make unlimited money, but I’ve always wondered what that really means.
Obviously just learning the language, in itself, won’t get you a $200k salary (or thousands of teens would have done it). Is it that businesses want experience with their specific codebases, or is old code somehow especially arcane, or what?
IIRC it’s mostly about the CICS database and being willing to do the work.
Kinda like Garbage truck mechanics make bank.
They’re just diesel mechanics, but working conditions.
It’s still not anywhere close to ‘unlimited money’.
That’s just the COBOL flavor of computing Stockholm syndrome.
The kids have made a much worse mess.
JS and libraries.
Hehe… I removed COBOL from my resume years ago… And to this day, I deny knowing COBOL
One of my EE professors noted that, decades ago.
Most people deny COBOL, it is shameful.
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.
Yep, learned COBOL in the early ’90s running the MicroFocus compiler from a 3 1/2 inch floppy on a 386 Windows 3.1 ‘puter. Spent enough time staring at my code, trying to find syntax errors to know that it was not my thing.
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.
Very coincidence I started in 1886 at age of 13 same as you First language Basic follow by COBOL using the green tabular sheets 80 columns I move for dbase III+ with cliper compiler
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
RPG! Yes, I would love to see a RPG/400 on Linux – externally defined files pulling from some db. And the cycle.
I have PTSD from doing Cobol assignments on a Burroughs mainframe for a computer class back in 1984.
The language wasn’t difficult, but punctuation was fussy and translating it to punch card data and then typing in that data perfectly to create the punch cards and lastly feeding the cards into the machine really sucked.
I have a lot of respect for those old Cobol coders. Writing code with no syntax errors and hand compiling it onto punch cards, all without mistakes took a special attention to detail.
Amusingly, the people who write about COBOL being a “legacy” language usually do so using Linux during a break from writing code in C or one of its more recent look-a-likes. I first encountered Unix and COBOL in the ’70s and C not much after. Yet, tell them that Linux is a “legacy” OS and some of them will split blood!
The “best” computer, OS or language is the one most suited to the task in hand. As the author of this article points out, COBOL is still the language of finance because it is the language best suited to that role.
Rather than denigrate it, learn it, get a contract with a bank and retire early! (The contract rates in COBOL are currently HUGE!).
COBOL was the second language I learned around 1886 at age of 13 in Mexico City, after basic. Using green tabular sheets 80 columns. You write in paper first before typing in the terminal, since you have to declare and add DATA structures as you develop the logic, you can’t go back and insert a line in the terminal easily. Later I move to dBaseIII+ with a cliper compiler to make EXE files in DOS
Forth <#, #, #>, HOLD inspired by the COBOL picture formatting?
As opposed to FORTRN FORMAT and c printf non-picture output approach?
Back around 1980, Zilog had a decent COBOL compiler for the Z80, running on their MCS development systems.
RPG and COBOL, two languages I ran across working for a US EMR company in the south-east.. Crazy that in 2025 there are EMR systems that have their entire financial systems running on COBOL based programs still.
PHP people are famously fond of saying “no one can know all the features of the language”. My theory is the cool kids paint COBOL as bad, cumbersome, and unpopular precisely because it is easy and it’s possible to learn it whole due to its scope. That leaves precious little room for prancing and preening or anecdotes about “I might have one of those laying around I should look for it one day. Strangers on the internet must hear of this immediately!”
In the 1970’s, a Lebanese instructor from Cal Poly SLO was in grad school with me at UCSB. His name was Emile Attala and he wanted to learn to ride a bike. I offered to help him learn in exchange for Cobol lessons. We had a few lessons of both. Once you learn to ride (they say) you never forget. Emile told me the most important thing in Cobol was “read the input record, write the output file”. It’s been over 50 years, but that stuck.