Brush up your COBOL: Why is a 60 year old language suddenly in demand?
Once upon a time, when the world and computers were new, I was in an Associate’s Degree program for Data Processing—there were no “computer science” programs then—in which I had to study accounting, math, statistics, and three computer languages: IBM/360 Basic Assembly Language, FORTRAN, and COBOL. By the 80’s, students were being told that COBOL was a dead language, and no one was studying it any more.
Now, in 2020, governments and banks are pleading for COBOL programmers, the language that wouldn’t die.
Governor Laura Kelly of Kansas said:
“So many of our Departments of Labor across the country are still on the COBOL system. You know very, very old technology,” Kelly said Tuesday. “Our Department of Labor had recognized that that was an issue and had initiated modernization, and, unfortunately, that’s something that takes time. This (virus) interfered and they had to cease the transition to a much more robust system. So they’re operating on really old stuff.”
New Jersey Governor Phil Murphy made a television appearance to plead for COBOL programmers to help.
So, how can you learn COBOL, make big bucks, and save lots of state agencies that need new code to deal with all the new government stimulus programs?
Let’s find out.
COBOL? What’s this COBOL?
COBOL stands for COmmon Business Oriented Language. One of the first of the high-level languages, it was put together by a group sponsored by the Department of Defense to develop a common business language. That group came to be called CODASYL—the Committee on Data Systems Languages—and defined a “common business oriented language,” drawing from Grace Hopper’s FLOW-MATIC, and other languages including Univac’s AIMACO and IBM’s COMTRAN. The resulting language went through more revisions, but rapidly became the dominant language for building business systems, and it has remained dominant since.
Plenty of companies still use COBOL, including IBM, UPS, and Cigna. Mario Ceballos, a software engineer at Cigna, told me, “The syntax is kept simple to allow non-programmers (“The Business”) to read it and understand it. COBOL is meant to be explicit, because there shouldn’t be room for assumptions.”
Of course, it has had its critics. In 1975, Edsgar Dijkstra famously proclaimed that “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence[sic].” This undoubtedly led to the decline of teaching COBOL in universities, but it remained the dominant business language.
But finding people with COBOL skills can be tough. “The mainframe is a very difficult platform to learn, and that’s due to the cost,” said Ceballos. “Individuals do not have the money to pay to lease a mainframe. A very small amount of schools teach courses on mainframes and COBOL. When IBM started remote work and outsourcing, they stopped incentivizing American schools to teach courses in Mainframes and COBOL. The talent pool shifted from on-shore to off-shore. Any local talent will be expensive with their consulting fees.”
Why is COBOL still dominant?
Compared to common programming languages today, COBOL is different, and in some ways very limited: you can’t do dynamic memory allocation, you can’t easily access low-level features of the operating system or particular computer architecture. The most common forms of the language can’t use recursion. You’d never want to write a compiler in COBOL. A computer science student presented with COBOL would be appalled.
This is a category error. In modern terminology, COBOL is actually a domain-specific language, specific to the particular domain of business programming. Robert Glass identified specific ways in which COBOL is better suited to business programming than general-purposes languages, among them:
- A business-oriented language needs to declare, manage, and manipulate heterogenous data. Business programs mix fixed and variable length strings, floating-point, integer, and decimal data with wild abandon in complicated record structures, often with variable parts. Database programmers are familiar with some of these issues, and object-relational mapping tools trip over these complexities regularly.
- Business and financial data needs to be managed using true decimal data types. Accounting systems must be correct to the last decimal digit and need to reproduce exactly the results of hand-calculation; conventional floating-point numbers lead to complexities and errors.
- A business-oriented language needs to access and manipulate large amounts of record-structured data maintained externally.
Now, none of this is beyond the capabilities of general-purpose programming languages, of course. But in COBOL, it’s native to the language.
We can debate the need for COBOL, but the fact is that hundreds of billions of lines of COBOL exist, and attempts to migrate away from COBOL have not generally been successful.
Your first COBOL program
The source files are simple text files. Having a useful programming editor with language support is as convenient for COBOL as any other language, if not more so. The easiest thing for a beginner is to use Visual Studio Code, the only competitor for my affections since EMACS.
There are surprisingly many VSCode extensions for COBOL. Right now, I’m using the bitlang code colorizer and Broadcom COBOL language support. A lot of the others are intended for people programming in a mainframe environment, but that adds complexity we don’t need for an introduction.
So, to summarize, to begin to experiment with COBOL:
- Download and install Visual Studio Code if you haven’t already.
- Install the bitlang.cobol and Broadcom COBOL Language Support extensions.
- Install GnuCOBOL. (Honestly, if anything is going to cause trouble, it will be this. The Homebrew installation on MacOS worked fine, and I don’t have other systems with which to test. On Windows, MicroFocus has a free trial for Visual Studio COBOL and Azure support for experimentation.)
There you are, you’ve installed everything and you’re ready to write your first COBOL program. As is traditional, we’ll start with the Ur-program, “Hello, world”.
So here’s your first surprise as a new COBOL programmer: COBOL cares about what column your code is in. In a traditional COBOL program, the source has several components:
Columns 1-6 are there for a sequence number. Column 7 is called the indicator area; in general, it’s mostly used to indicate comments by putting an asterisk ‘*’ in that column. Code then goes in columns 8 through 72, and columns 73-80 are basically free for the programmers use.
This is all based around the days when we put our source into 80-column Hollerith cards.
Modern COBOL compilers also accept a free format which doesn’t force your code into the 80-column straitjacket, but a very large proportion of existing code is still in the card-image format. For right now, we’ll stick with card images.
Brace yourselves: COBOL is not a block-structured language like nearly any other language you’ve ever used. A major design goal for COBOL from the first was that it should be “self-documenting” with an English-like syntax. Instead of having functions or subroutines and blocks, we have divisions, sections, paragraphs, and statements. (We’ll see something almost like a subroutine with the PERFORM
verb below.)
Oh, right, we also have verbs for COBOL operators.
Here’s “Hello, World” in COBOL:
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
PROCEDURE DIVISION.
DISPLAY "Hello, world".
END PROGRAM HELLO.
Compared to some languages it’s a little wordy, but honestly not so bad. Compare it to a simple Java version:
public class Hello {
public static void main(String[] args){
System.out.println("Hello, world!");
}
}
Like all “Hello, world” programs it doesn’t do much—but if you’ve been told that it takes 90 lines to write a basic program in COBOL, well, you’ve been misled.
Now let’s take the “Hello world” program apart for our first example.
The first line is:
IDENTIFICATION DIVISION.
COBOL programs always have at least an identification division and a procedure division. The identification division has one important paragraph, the PROGRAM-ID
. You need to give the program a name here. The name doesn’t need to correspond to the file name or pretty much anything, except when your COBOL program is being called from another COBOL program. This is through the CALL
verb, which we’re not going to cover.
We do need to have a program ID, so we add
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
There are a lot of other things that commonly go into the identification division. I’ll add a couple of common examples.
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
AUTHOR. CHARLES R MARTIN.
DATE-WRITTEN. 2020-APR-11.
In modern environments, however, these are comments.
Speaking of modern environments, by the way, COBOL doesn’t require all-caps like I’ve been using. GnuCOBOL would be perfectly happy with
identification division.
program-id. tut2.
author. charlie martin.
procedure division.
display "hello, world".
end program tut2.
I’m just having a little misty-eyed nostalgia here.
Don’t judge me.So let’s finish up our “Hello, world.” The execution part of a COBOL program is in the procedure division.
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
PROCEDURE DIVISION.
DISPLAY "Hello, world".
END PROGRAM HELLO.
There’s one more bit of card-image format here. Notice that `DISPLAY “Hello, world”` is indented four columns. That’s because the part from column 8-72 actually has two parts: the A section, from column 8-11, and the B section from column 12 on. Divisions, sections, and paragraphs need to start in the A section; code statements should start in the B section.
Extended COBOL Example
Of course, “Hello, World” doesn’t really give you a good picture for any language, so let’s look a little deeper into COBOL with something that at least resembles a real business program. We’re going to use a pretty common example: computing a paycheck for hourly employees, including computing Federal, State, and FICA tax.
Having done it, I can tell you this is not an easy thing to do in reality—the tax tables are complex and arcane—so we’re going to simplify and make the Federal tax rate 16.4 percent, state 7 percent, and fix the FICA rate at 6.2 percent while carefully choosing our pay rate and hours worked to not hit the FICA cap. We’re only doing hourly workers, and we compute hours over 40 as overtime at 1.5 times the base rate.
No point in repeating the identification division. We start with a new division, the environment division, which exists to collect the interface between the COBOL program and the outside world.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT TIMECARDS
ASSIGN TO "TIMECARDS.DAT"
ORGANIZATION IS LINE SEQUENTIAL.
Once again, we’re going to exercise some aspects of COBOL that will be surprising to people who haven’t worked in the record-oriented world of data-processing. In UNIX, Linux, MacOS, or Windows, a record is a line of text followed by some end of line character or characters. This causes a problem for traditional COBOL, but COBOL compilers implement a non-standard extension to handle this: ORGANIZATION IS LINE SEQUENTIAL
.
The input-output section simply assigns a symbolic name (TIMECARDS
) to the file and connects it to the file in the outside environment.
The next part of the program describes the data we’re working with. In COBOL, all data is generally presumed to be contained in fixed-format records. Those records have a hierarchical structure that’s indicated by the level numbers: 01 is the top level, and subdivisions get higher numbers. I used 02, 03, and so forth, but that’s arbitrary; we used to use 01, 05, and so on because it was easier to insert cards without repunching them all.
But now we introduce another division, the data division. As you probably guessed, this is for data. We’re using two sections. First is the file section.
DATA DIVISION.
FILE SECTION.
FD TIMECARDS.
01 TIMECARD.
02 EMPLOYEE-NAME.
03 EMP-FIRSTNAME PIC X(10).
03 EMP-SURNAME PIC X(15).
02 HOURS-WORKED PIC 99V9.
02 PAY-RATE PIC 99.
This is our input, which is fixed format; we’re connecting it to the TIMECARDS
file with the FD
line. Following that is the working storage section. It looks a little unfamiliar if you’re not used to COBOL, but really, I’m just declaring variables I’ll use in the program later.
WORKING-STORAGE SECTION.
* temporary variables in computational usage.
* intermediate values for computing paycheck with overtime
01 REGULAR-HOURS PIC 9(4)V99 USAGE COMP.
01 OVERTIME-HOURS PIC 9(4)V99 USAGE COMP.
01 OVERTIME-RATE PIC 9(4)V99 USAGE COMP.
01 REGULAR-PAY PIC 9(4)V99 USAGE COMP.
01 OVERTIME-PAY PIC 9(4)V99 USAGE COMP.
* computed parts of the paycheck
01 GROSS-PAY PIC 9(4)V99 USAGE COMP.
01 FED-TAX PIC 9(4)V99 USAGE COMP.
01 STATE-TAX PIC 9(4)V99 USAGE COMP.
01 FICA-TAX PIC 9(4)V99 USAGE COMP.
01 NET-PAY PIC 9(4)V99 USAGE COMP.
The unfamiliar part of this is the PIC
(or PICTURE) clause. COBOL is not strongly typed at all. Instead, more like C, every declaration is identifying a piece of memory; the PIC
tells COBOL how to interpret that memory with a “picture”. In this case, 9(4)v99
tells COBOL that a chunk of memory named, for example REGULAR-HOURS
is to be interpreted as a six-digit number that is assumed to have a decimal point (the V
) in front of the last two digits. USAGE COMP
tells COBOL to use an internal format that’s suited to fast arithmetic. What that format actually is is somewhat flexible and depends on the architecture, which means you’d best not depend on it being the same everywhere.
If you want to be confident of this, don’t use USAGE COMP
, which leads to another part of the data, the format for a check to be output. These fields are the default usage, which is printable where USAGE COMP
is not.
01 PAYCHECK.
02 PRT-EMPLOYEE-NAME PIC X(25).
02 FILLER PIC X.
02 PRT-HOURS-WORKED PIC 99.9.
02 FILLER PIC X.
02 PRT-PAY-RATE PIC 99.9.
02 PRT-GROSS-PAY PIC $,$$9.99.
02 PRT-FED-TAX PIC $,$$9.99.
02 PRT-STATE-TAX PIC $,$$9.99.
02 PRT-FICA-TAX PIC $,$$9.99.
02 FILLER PIC X(5).
02 PRT-NET-PAY PIC $*,**9.99.
The only really fun stuff here is that we have some new PIC
formats: $,$$9.99
has a leading dollar sign that is always against the leftmost digit, and $*,**9.99
fills the space between the dollar sign and the first digits with *.
I’ll show the entire program shortly, but I do want to point out the way COBOL does math, as in COMPUTE-GROSS-PAY
:
COMPUTE-GROSS-PAY.
IF HOURS-WORKED > 40 THEN
MULTIPLY PAY-RATE BY 1.5 GIVING OVERTIME-RATE
MOVE 40 TO REGULAR-HOURS
SUBTRACT 40 FROM HOURS-WORKED GIVING OVERTIME-HOURS
MULTIPLY REGULAR-HOURS BY PAY-RATE GIVING REGULAR-PAY
MULTIPLY OVERTIME-HOURS BY OVERTIME-RATE
GIVING OVERTIME-PAY
ADD REGULAR-PAY TO OVERTIME-PAY GIVING GROSS-PAY
ELSE
MULTIPLY HOURS-WORKED BY PAY-RATE GIVING GROSS-PAY
END-IF
.
Yes, standard COBOL makes you spell it out.
So here’s the full program.
IDENTIFICATION DIVISION.
PROGRAM-ID. PAYCHECKS.
AUTHOR. CHARLES R. MARTIN.
DATE-WRITTEN. 2020-APR-15.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT TIMECARDS
ASSIGN TO "TIMECARDS.DAT"
ORGANIZATION IS LINE SEQUENTIAL.
DATA DIVISION.
FILE SECTION.
FD TIMECARDS.
01 TIMECARD.
02 EMPLOYEE-NAME.
03 EMP-FIRSTNAME PIC X(10).
03 EMP-SURNAME PIC X(15).
02 HOURS-WORKED PIC 99V9.
02 PAY-RATE PIC 99.
WORKING-STORAGE SECTION.
* temporary variables in computational usage.
* intermediate values for computing paycheck with overtime
01 REGULAR-HOURS PIC 9(4)V99 USAGE COMP.
01 OVERTIME-HOURS PIC 9(4)V99 USAGE COMP.
01 OVERTIME-RATE PIC 9(4)V99 USAGE COMP.
01 REGULAR-PAY PIC 9(4)V99 USAGE COMP.
01 OVERTIME-PAY PIC 9(4)V99 USAGE COMP.
* computed parts of the paycheck
01 GROSS-PAY PIC 9(4)V99 USAGE COMP.
01 FED-TAX PIC 9(4)V99 USAGE COMP.
01 STATE-TAX PIC 9(4)V99 USAGE COMP.
01 FICA-TAX PIC 9(4)V99 USAGE COMP.
01 NET-PAY PIC 9(4)V99 USAGE COMP.
* print format of the check
01 PAYCHECK.
02 PRT-EMPLOYEE-NAME PIC X(25).
02 FILLER PIC X.
02 PRT-HOURS-WORKED PIC 99.9.
02 FILLER PIC X.
02 PRT-PAY-RATE PIC 99.9.
02 PRT-GROSS-PAY PIC $,$$9.99.
02 PRT-FED-TAX PIC $,$$9.99.
02 PRT-STATE-TAX PIC $,$$9.99.
02 PRT-FICA-TAX PIC $,$$9.99.
02 FILLER PIC X(5).
02 PRT-NET-PAY PIC $*,**9.99.
* Tax rates -- 77 level aha!
77 Fed-tax-rate Pic V999 Value Is .164 .
77 State-tax-rate Pic V999 Value Is .070 .
77 Fica-tax-rate Pic V999 Value Is .062 .
* 88 Level is for conditions.
01 END-FILE PIC X.
88 EOF VALUE "T".
PROCEDURE DIVISION.
BEGIN.
PERFORM INITIALIZE-PROGRAM.
PERFORM PROCESS-LINE WITH TEST BEFORE UNTIL EOF
PERFORM CLEAN-UP.
STOP RUN.
INITIALIZE-PROGRAM.
OPEN INPUT TIMECARDS.
PROCESS-LINE.
READ TIMECARDS INTO TIMECARD
AT END MOVE "T" TO END-FILE.
IF NOT EOF THEN
PERFORM COMPUTE-GROSS-PAY
PERFORM COMPUTE-FED-TAX
PERFORM COMPUTE-STATE-TAX
PERFORM COMPUTE-FICA
PERFORM COMPUTE-NET-PAY
PERFORM PRINT-CHECK
END-IF.
COMPUTE-GROSS-PAY.
IF HOURS-WORKED > 40 THEN
MULTIPLY PAY-RATE BY 1.5 GIVING OVERTIME-RATE
MOVE 40 TO REGULAR-HOURS
SUBTRACT 40 FROM HOURS-WORKED GIVING OVERTIME-HOURS
MULTIPLY REGULAR-HOURS BY PAY-RATE GIVING REGULAR-PAY
MULTIPLY OVERTIME-HOURS BY OVERTIME-RATE
GIVING OVERTIME-PAY
ADD REGULAR-PAY TO OVERTIME-PAY GIVING GROSS-PAY
ELSE
MULTIPLY HOURS-WORKED BY PAY-RATE GIVING GROSS-PAY
END-IF
.
COMPUTE-FED-TAX.
MULTIPLY GROSS-PAY BY FED-TAX-RATE GIVING FED-TAX
.
COMPUTE-STATE-TAX.
* Compute lets us use a more familiar syntax
COMPUTE STATE-TAX = GROSS-PAY * STATE-TAX-RATE
.
COMPUTE-FICA.
MULTIPLY GROSS-PAY BY FICA-TAX-RATE GIVING FICA-TAX
.
COMPUTE-NET-PAY.
SUBTRACT FED-TAX STATE-TAX FICA-TAX FROM GROSS-PAY
GIVING NET-PAY
.
PRINT-CHECK.
MOVE EMPLOYEE-NAME TO PRT-EMPLOYEE-NAME
MOVE HOURS-WORKED TO PRT-HOURS-WORKED
MOVE PAY-RATE TO PRT-PAY-RATE
MOVE GROSS-PAY TO PRT-GROSS-PAY
MOVE FED-TAX TO PRT-FED-TAX
MOVE STATE-TAX TO PRT-STATE-TAX
MOVE FICA-TAX TO PRT-FICA-TAX
MOVE NET-PAY TO PRT-NET-PAY
DISPLAY PAYCHECK
.
CLEAN-UP.
CLOSE TIMECARDS.
END PROGRAM PAYCHECKS.
Here’s the data file:
Charlie Martin 41015
Terry Lacy 32007
and here’s the output:
$ cobc -x paycheck.cob
$ ./paycheck
Charlie Martin 41.0 15.0 $622.50 $102.09 $43.57 $38.59 $**438.25
Terry Lacy 32.0 07.0 $224.00 $36.73 $15.68 $13.88 $**157.71
$
Resources to learn COBOL
There are actually quite a number of courses and books to learn COBOL. Many of the courses are from overseas, because offshoring firms have been meeting the demand for COBOL for years.
I bought and ran through this Udemy course, which is pretty good, and among several COBOL books on Kindle, I like Beginning COBOL for Programmers by Michael Coughlan. There are a mountain of YouTube videos, of which I only looked at a few. This one seems good, but search for COBOL and you’ll find lots more.
There will be more to come as well. On April 9th, IBM and the Open Mainframe Project announced a joint project to connect states with COBOL skills and to teach COBOL Programming. It has several resources, including a bulletin board for COBOL programmers who want to get back in the business, and the beginnings of an open source COBOL course.
Why does COBOL have a bad reputation?
As you can see from this little example, COBOL is not like your normal programming language. You can’t write a compiler or a kernel module in COBOL, and the syntax is not what we’ve grown to expect. But then consider another common domain-specific language: SQL. The syntax is kind of weird, and the semantics depend on relational algebra.
“Programming on the mainframe gives you a glimpse on how software used to be built,” said Ceballlos. “It’s like a time capsule for any modern programmer. Most of it is still very manual compared to modern DEVOPS and automation techniques.”
COBOL is, in a lot of ways, an antiquated, bad programming language. But for its particular domain, it’s better than anything else.
Tags: bulletin, cobol, stackoverflow
160 Comments
I am going to have to agree with Edsgar Dijkstra that “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence”. I would even add, punishable by life in prison. That said, if there is someone who never will become a decent programmer due to the lack of intellect, would want to learn it, given a lot of money is offered for those willing to destroy their minds, I would consider teaching such a person almost forgivable.
In 1994 I wrote some COBOL programs (COBOL85 on Siemens BS2000) that ensure M2M communication between several mainframes, used by a system delivering services for +10M people. The programs are still running, 36 years later (on new hardware and new versions of the OS) …
@Christian S.: I also wrote programs in IBM Basic (1986), MS-Basic (1987), MS-Visual Basic (1998 and 2008), Delphi (2002), Assembly + Natural/Adabas on Siemens BS2000 (1992), R /Shiny (2014), and some proof of concepts in C and Python (2010).
It’s only 26 years later, isn’t it? Still: point taken.
COBOL
I was born in 1937. I graduated from the Faculty of Economics in Sarajevo in 1964 (28). I started making programs at COBIL 1982 (45).
I performed the practice of designing the economic infosystem module and program development in COBOL in the field of economic calculations and bookkeeping (attached study: INFORMATION AUTOMATION).
I still do that today and I write about it at the age of 85.
Language: Bosnian.
Sarajlić Asim dipl.ecc.
Mail:
I am asking your e-mail address to send you a study on my COBOL practice. Thanks.
Well, congratulations. And yet COBOL is a very effective programming language.
I was a COBOL Programmer from 1985 until 2004.
I once wrote a windows program using microsoft cobol. Learned EBCDIC dump reading. Positive 1. looked like a J in the dump due to overpunch.
I miss those days. I stiill remember JCL. good memories… no email jail, no software install worries. Give me. ack my green 3278 dumb terminal…
I preferred the 3179G myself.
who doesnt.
I preferred the 3179G myself.
I was one of the best COBOL programmer’s in saudia airlines
Not many Cobol jobs in Australia. And the few are mainly for Aussie citizens due to baseline clearances. I would love a Cobol remote job. I have more than 20 years experience in Cobol.
COBOL
Rođen sam 1937. Diplomirao na Ekonomskom fakultetu u momSarajevu1964 (28). Ja sam počeo praviti programe u COBILU 1982 (45).
Praksu projektovanja modula ekonomskog infosistema i izradu programa u COBOL obavljao sam u domeni ekonomskih obračuna i knjigovodstva (prilog elaborat: INFORacija autoMATIZACIJA).
To i danas radim i o tome pišem u 85 godini života.
Jezik: bosanski.
Sarajlić Asim dipl.ecc.
Mail: asim.sarajlic470@gmail.com.
COBOL
I was born in 1937. I graduated from the Faculty of Economics in Sarajevo in 1964 (28). I started making programs at COBIL 1982 (45).
I performed the practice of designing the economic infosystem module and program development in COBOL in the field of economic calculations and bookkeeping (attached study: INFORMATION AUTOMATION).
I still do that today and I write about it at the age of 85.
Language: Bosnian.
Sarajlić Asim dipl.ecc.
Mail:
Why exactly is it a criminal offense? On a basic level COBOL is just another DSL, and last I checked people don’t think badly of those who use Erlang or AWK in their proper areas.
How can teaching / learning COBOL be a sin when billions of lines of code have been written supporting almost all Businesses domains, Banking, Insurance, HealthCare, Retail & Government to name a few? Industry needs COBOL developers to maintain or convert this language code to newer languages, right? It’s COBOL that’s still running the ATMs we draw money from after all, just an example!! .. Sin? Life imprisonment? I don’t get it, sorry!
COBOL has been my second Mother since 1980s. Four decades of programming in this “English-like” oldest language, still coding COBOL, I feel proud that my entire employment to date has been based on COBOL, my bread and butter.
I coded COBOL from 2005 to 2012, its nice. I love it
The Santader Bank from Spain not to much years had a vry large systems working with this Language.
This Bank has many branches working with this language, robots mounting information tapes and thousands of branches around the world. They know why COBOL is a very fast language.
COBOL is a very specific programming language. I’m coding in COBOL/CICS/JCL and DB2 since 1998. In these years i used a lot of any languages, C, C++, Java, Php in a variety of production environments. Any language has its specific domain. It’s a mistake in my opinion to think to migrate COBOL programs in an another languange. The entire process should have to be “rethinked”.
That’s why there are still a lot of work for me and who know this language. I don’t think my brain is crippled. I’m confronting with a lot of problems any day on the bank mainframe where I work and any day my knowledge of this world dramatically increase.
Awesome to hear this that you are still using COBOL having used other languages as well. Totally agree on your point of “…rethinked”.
I don’t see the COBOL jobs in India if the experience is more than 8 – 10 years. Probably because a 5 year experienced programmer can learn and do what a 15 year programmer can do. So I had to shift to another area of work. Though still would love to work on COBOL.
I disagree with the 5 vs. 15 year comparison. A lot of positions only require 5 years because of the type of programming required. If you are only a coder, then only syntax and basic structure knowledge is really needed. If you are involved in streamlining programs to make them much faster, then that will require more experience.
Another thing I have found is that people become expert in different facets of COBOL programming. Some excel in the JCL side. Others can pump out code quickly (but usually not efficiently). Still others can speed up programs by reducing CPU run-time, I/O bound programs and thus reducing clock time.
The industry favors those who can pump out code quickly as well as JCL experts, until their code becomes bogged down. Very often the IT industry blames the language for the slowness rather than those who created the problems.
It took me 5 years to learn how create efficient programs. It took another 5 years to learn how to fix other people’s slow programs. I am still learning how to make code run faster. So, 15 years experience is better than 5 years. It’s just more difficult to find a position requiring that experience.
Hey guys I’ve been coding Cobol and JCL since 1973. Anyone remember Easytrev or U.F.O (User Forms Online). How about VSAM files and of course the dreaded core dump.
I started coding COBOL and JCL on punch cards in 1971. Gravitated to VSAM, DB2 and CICS as time went by. I remember Easytrev and U.F.O. I was forced out in the 1980s when the banking industry in my area decided that “offshoring” was good for the country (no to mention their pocketbooks).
I’m a dinosaur who in brushing up on my skills, (if for no other reason) to keep my brain active.
I worked on IBM mainframe COBOL and assembler for around 34 years until 2009.
Recently I’ve been offered some COBOL work!
Been out of IT since then!
Wrote about this a while ago myself:
https://medium.com/@cseder/cobol-60-years-of-proven-business-rules-still-going-strong-51abf54de123
it doesn’t seems easy to learn for a javascript developer.
That’s a whole new rant, but my experience with teaching new programmers at bootcamps and as a Wyzant tutor (https://www.wyzant.com/Tutors/CharlieM) is that we teach _coding_ but not _programming_. Programming in COBOL is pretty easy, actually — but it requires generalizing from what you learn programming in one language.
it doesn’t seems easy to learn for a javascript developer.
COBOL is actually easier for me to read than Java. COBOL makes much more sense in what a statement is doing when you read it.
It’s kinda like coding and commenting all together.
That was part of the point, although readable by non-programmers turns out to be less of an advantage than they originally expected. But it’s very explicit, and far less vulnerable to cute little programming tricks.
COBOL has a lot of boilerplate, but oddly comparable in size to Java, and the boilerplate is at least in pseudo-English with few special characters. But it’s still possible to arrange your WORKING-STORAGE so that business logic requires the following line of code…
ADD VERMOUTH TO GIN GIVING MARTINI
Readability by business analysts (technical systems people, who were not programmers) could be of some advantage in reading and specifying narrow sections of an application program to be sure the business logic matched the business needs. But practically, deep knowledge of the application design, data set, magtape and disk pack mounting orders and operating procedures required by the specific application, as well as assumptions about the execution environment and business assumptions, was still necessary to make any practical sense of a complex COBOL program. Modern systems have done away with manual file handling (mostly), but I’d argue the other concerns remain.
I think we need to bring back several disciplines: the COBOL programmer, yes; but also the Business Analyst who understands the inner workings of the Unemployment Benefits System and can translate business requirements into a system design change order. And the Systems Analyst who understands how to organize mainframe operating resources to support the running of the application.
Absolutely agree on that! You could focus on solving the business problem and didn’t had worry about all the finicky stuff like having 25 different frameworks in the right version and a degree in quantum physics to even get a “Hello World” on your screen. I couldn’t care less which browser version it has to run, it just fucking worked on the terminal!
Totally agree!
Reminds me, indeed with misty eyes, when we were kings… Kings of COBOL programming that is.
I truly withheld tears when I sighted the IBM COBOL Coding Form in this article. How time has changed.
Some years ago I was working at IBM in Rochester Minnesota on OS/400. They have a collection of museum pieces, including an IBM System/3 Model 10, my very first computer. I did indeed get a little misty.
My first one, back in 1967, was an IBM 360!
80 col. cards Console typewriter. 6 reel to reel tape drives and 4 10 pack disc drives.
The other office staff called it the God machine.
It had an air-conditioned room with an elevated floor, distilled air humidifier and was on the main floor because it was too damp in the basement but they could work there.
Nice. I worked for a software vendor that sold an application running on system/38 and then AS/400. After several years working for them, I went out on my own and purchased an AS/400 model D04 back in about 1992. I think it had two 400MB disks and maybe 8MB or 16MB of RAM? I can’t recall anymore. In my case, I wrote mostly RPG and not COBOL.
COBOL has been my second Mother since 1980s. Four decades of programming in this “English-like” oldest language, has brought tears in my eyes as well as I sighted the Coding Form (though I haven’t used much!). How can teaching / learning COBOL be a sin when billions of lines of code have been written supporting almost all Businesses domains, Banking, Insurance, HealthCare, Retail & Government to name a few? It’s COBOL that’s running the ATMs we draw money from after all!! .. Sin? Life imprisonment? I don’t get it, sorry!
How changed has time. Where is Y2K Cobol boom in this story? Back when I was a satellite operator, it was common knowledge in the Air Force that pantloads of Cobol programmers would have to be hired. My theory was that it was built intentionally for a planned obsolescence due to the prediction that a Solar Storm would knock us off the rails by around 2001, to say nothing of the emps from the two total nuclear wars miraculously averted in Cheyenne Mountain in 1979 by a Major General who stood down people who had him at gun point while he insisted to recheck and a computer operator courageously identified his error hanging a strike simulation magnetic tape and in 1983 when a Soviet General did a similar buck during a Reagan era war game that somehow didn’t get communicated. Al Haig saying “I’m in charge here in the White House” and being taunted mercilessly when it was absolutely the right thing to do to communicate ASAP with the Soviets with President Reagan downed by Hinkley not having access to that “phone.”
Anyway I can remember the topic coming up when I mopped the floor with Prince’s 1999 blasting and in retrospect that’s about one penny short of a twenty after all the advertising we’d been brainwashed with and not a date because of course there was never a year zero.
How the heck could anyone come up with enough “man”hours of Cobol programming to troubleshoot all that verbose inelegant poorly documented code for things like banks and grids around the world? Maybe it’s a military thing, but everyone loathed cobol.
So to all you cobol programmers: Thank you for your service!
Your welcome!
Well this was a fantastic experience. It took me back to the late 70s when I wrote Fortran using punched cards. I never learnt COBOL. Now I use JavaScript. I did it the old fashioned way, hacking by hand and doing the edit compile fix routine manually. The first time I compiled I had about a hundred errors – most spelling errors, often missing statements (I did each line by hand), lines starting in the wrong columns and the debugging line by line and then learning that I could use DISPLAY to help figure out what was going wrong. I simplified your program to just do a simple tax calculation. Eventually I got it all to work and experienced the great pleasure that only programmers can get when they crack it. (Only sex has the same effect – lol).
Thanks for your efforts on this.
Couple of suggestions: the first line one char indent is odd. I guess this is a formatting error. Cab you structure the code with nicer indents or is this not “proper”? Is there any way you can make the column numbers clearer in the code and especially the data – maybe a pale background?
Thanks so much.
Now at 60 and about to be made redundant from my teaching (computer science) job, maybe I can get a job COBOL programming – bit ironic don’t you think 🙂
Gordon
The mystery one space on the first line is some weirdness in the blog software. It’s not in my sources. And yeah, it is a little ironic.
I was a S/370 mainframe operator in the late 70s / early 80s. I wrote a program in COBOL to play blackjack on the system console, for those long 3rd shifts when the IMS database updates were running.
Everything that happened on the 3270 CRT printed out on the console hardcopy log. The operations manager was annoyed that i was playing blackjack on company time, but I pointed out that it meant I was at the console monitoring batch processing status, so they let it go.
It’s always fun digging up and trying old languages out of course – but I have to challenge this premise:
“Why is a 60 year old language suddenly in demand?”
Cobol isn’t suddenly in demand at all – one particular system needed a few Cobol devs because of a Covid-19 related issue. Because it was Covid related it made the news, and now every man and his dog seems to believe there’s suddenly a massive worldwide shortage of Cobol devs…
I have worked with COBOL around 2007-08 for 9-10 months (and even languages like PL/I that none of my current colleagues have heard about). By the end of that period, not only COBOL , I though I was done with programming altogether!
Fortunately I didn’t give up on programming, and I’m still writing code.
Yes, it’s true COBOL still runs in the background for many huge systems, specially old insurance and finance companies. And mainframes are pretty powerful and robust, even for today. So, in this time, when some very rich companies are not able to move away from COBOL, someone might be able to make some good money working with COBOL. That’s really a good opportunity. BUT,
1. For young developers, it might not be good idea for their long term career. COBOL’s applications & programming paradigms, take one’s mindset far away from all modern programming ideas
2. It’s just plain torture on the brain
Great blog! I bought the course just now for just 12.99! The offer was still valid for 5 hours for anyone who also reads this. In this time of lockdown learning COBOL can keep me off of the streets ;).
COBOL was great for implementing structured code, once we got rid of the GOTO statement. Mathematically provable too.
I thought that Dijkstra was arrogant, but I must agree with him. I dislike this a lot, it is even worse that Perl or Javascript.
Still, it is workable, and while obviously difficult to maintain, it is simple, and simple has big benefits.
having seen both cobol and perl very superficially, I think cobol is more clear in its intents than perl.
JS on the other hand has TS, so fully agree on that
I learnt COBOL in 1992 and it was fun.
Created two systems and completed.
I has helped me understand today’s systems without even going back to college.
If this is true, then why not revive my memories?
COBOL looks much like ABAP. Or ABAP looks much like COBOL.
There was something like CONCATENATE x y INTO z RESPECTING BLANKS
And no code completion of course.
It does, and I’m sure it’s no coincidence.
I was an operator on the first IBM 360/75 in London way back in the 60’s at the CEGB in Victoria.
I managed to teach myself Cobol – my first program ran on an IBM 360/30 with 8k of memory. The machine was housed in a large air-conditioned room and took up a large amount of space with its disk and tape drives, card reader and punch and line printer.
I can see a few differences in the format then to what it is now – but not many.
I now program in PHP and Javascript etc but seeing this brought back a lot of fond memories
I have 18 years hands on experience as a mainframe developer. I know COBOL, REXX. JCL, Assembly Language Code (ALC) and many mainframe tools.
I work as a IT manager for the state. Currently, since it is my area expertise, I have decided to open up to the demand of opportunities in legacy programming. I have a fully functional office where I am able to work remotely. I have a BA in Information Systems Management and referrals if needed.
Email: Regina at reginalwofford@gmail.com.
Regina, check out the link in Resources for a bulletin board for COBOL programmers.
Oh I so forgot abut REXX!
You didn’t explain what NEXT SENTENCE means! This article doesn’t get anywhere close to explaining the pain of COBOL maintenance. People on stackoverflow are constantly saying that exceptions are not structured etc. It’s all crap. You don’t understand what a non-structured program is until you’ve dealt with COBOL. Don’t be fooled. It really is a terrible language.
How about Perform Thru function OMG
PERFORM {Routine/paragraph/Section}
THRU {Routine/paragraph/Section}
It’s not the language that’s terrible, it’s what “programmers” make with it! If you have a lazy ass programmer that doesn’t think a second about design, you get terrible and unmaintainable code. No matter what the language is. Other languages might force you to be more structured etc. but at the end the problem is between the chair and the keyboard.
To be fair, language design usually takes into account that people do well with boundaries. As you said, thinking about the design is much better than not; so much so that it’s worth forcing. Kinda like saying “you’re an idiot for jumping off a cliff, you shouldn’t need a fence to prevent that!”, and while true, the fence is still really nice to have. You can still jump the fence, but most programmers won’t go that far. I’m a fledgling programmer myself (last year of my Bachelor’s in CS) and it would have been a nightmare for me to properly learn concepts without forced structure like strong typing and object orientation.
And if you anyone claims that COBOL is “simple”have them read the grammar: https://www.cs.vu.nl/grammarware/browsable/cobol/ Compare that to Python: https://docs.python.org/3/reference/grammar.html. Even the Java grammar is much much simpler: https://github.com/antlr/grammars-v4/tree/master/java
What you’re saying is it’s had to write a COBOL compiler, not that it’s hard to write a COBOL program. And what do you expect: it was developed about 20 minutes after the Chomsky hierarchy was defined.
I think the implication of saying that the COBOL language is not simple is that it is complex and useful. It certainly cannot be assumed that the implication is that it is hard to write COBOL.
@Jimmy James – Next Sentence, as well has periods to terminate scope have all been obsolete since Cobol-85
I must have missed something.
I see capacity issues, not code maintenance issues.
As for the merits of the language, yeah: sure Ive seen shitty COBOL.
But I’ve seen shitty C, PHP and Python too.
If someone doesn’t know how to design systems or use languages the product is going to suck regardless.
Amen! Exactly what I preach to all those smart kids every day!
Thank you for the Micro Focus mention Mr. Martin.
If anyone would like to try Visual COBOL to develop in Visual Studio, Eclipse on Azure you can download free trials here.
https://www.microfocus.com/en-us/products/visual-cobol/try-now
We also have a companion guide here https://www.microfocus.com/resources/guides/visual-cobol/
And plenty more information about Visual COBOL here https://www.microfocus.com/en-us/products/visual-cobol/overview
Programmed for IBM Mainframe years ago, and had to learn the basic of the Mainframe, High level assembly, Cobol, CICS, VSAM, JCL etc.
Learn COBOL is not the hardest part, but to use all of the stuffs is very hard. It is a totally different world compared with Unix/Linux or Windows.
I agree the COBOL language isn’t the hard part but rather that ecosystem around it will be completely foreign to most with a steep learning curve. The saving grace is mainframe technical documentation is excellent compared to other operating systems. I kept an old IBM/370 Principals of Operation manual for posterity, not that I consult it nowadays.
I had to approve a COBOL course in the school in the 80s, I learned the language and approved the course passing an exam to forgot everything for mental hygiene. I had not read Dijkstra’s statement about COBOL at that time, but programming languages was already one of my favorite subjects. What cold be of interest to me of COBOL, when I learned Fortran (ratfor), Pascal, Prolog, Lisp, etc. Nothing!
At that time IA was rising in popularity due to the famous Fifth Generation Project in Japan, and many other IA research in all the world.
Many systems said that they had IA technology, when that was not true, just for marketing purposes. “commerce lies”.
At the late 80s OOP, came into the scene, and many aboarded that new “main stream”. (and fortunately IA was abandoned by the opportunists.)
OOP, promised a better more modular software, due to the absolute ban of global variables, the pain on the neck of COBOL maintenance programmers. Although it was more complex than structured programming, the bad COBOL code didn’t followed a structured programming discipline.
E.W.Dijstra also criticized OOP, Alan Key hated Dijkstra for that statement, and blamed him as arrogant. (there is a very chauvinistic discourse of Alan Kay against E.W.Dijkstra in Youtube.)
I agree with Dijkstra absolutely! He was not arrogant at all, he always insisted solving a problem one must focus on the problem trying to understand the esence of the problem, the core, using a complex language to reason adds more complexity to the reasoning. Isn’t that the famous Ockham’s razor?
Dijkstra always searched the most simple notation, to concentrate in the solution to the problem, and he was right. That’s all, no bad intention at all.
Today C++ and other OO languages are predominant, but C++ handbook has about 1500 pages and hunderd of tokens.
Barnje Stroustroup is crazy if he really thinks that his language is better than the parsimonious C, with just thirty something keywords.
The OO is not better than COBOL, if one knows how to program, one can write good code, well structured programs in the very, very, very worthy COBOL. I can generate very well structured programs in COBOL if someone wants to pay me a lot of money for that.
COBOL has records (structures), unions (variant types) and even a restricted form of exponential types (passing procedure names).
It lacks good subroutine structure, the standard is not recursive, and has no dynamic memory allocation, but, man I programmed in Fortran IV, where I implemented trees, to write portable code I implemented recursion with an array stack. The trees were also implemented with arrays.
But I could (i am not willing to program in it ok!) program in COBOL better than any OO language, that cripples the mind deeper than the naive verbosity of COBOL. OOP makes one to think everything in a very anthropomorphic way, that is more bureaucratic than the “fill all this forms” philosophy of the IDENTIFICATION DIVISION.
There is also a big problem in maintaining ill designed systems in OOP languages.
The problem with legacy systems is that they were written at a time where few well trained programmers existed, there were a lot of improvisation.
After all, it was very easy to program in COBOL it was almost English. I knew a COBOL programmer that was originally an office boy, but was invited to be a programmer with the main frame provider for a couple of weeks and almost all programmers in his team had the same formation.
That was very common, the consequence was that they were not taught to understand data structures, just the classical batch snippet (additions, deletions, changes).
All those legacy systems could be ported to newer languages, but they will fail in most cases if they choose an OO Language.
It could be better to improve the structure of ill written programs, removing global variables as much as possible, trying to infer the almost always nonexistent or incomplete specification, and so on. There is no need to write new programs in COBOL, but that causes not too much harm if it is done with lot of care, by an educated staff, using the educated term in the sense given by Dijkstra.
When I was young, I failed to convince the managers in charge of the legacy systems in a financial company to do those improvements offering to train the programmers as a part of my work in the company, but it was rejected because “I had to learn more about real life programming not my theoretical school background”, however, they had to make important changes because by 1992, the Mexican money lost 3 zeros. Although I was not a COBOL programmer I gave the solution, which was implemented by my coworker (older than me), an educated programmer knowing COBOL, after discussing stream processing with him, he wrote a COBOL program generator. but that simple tool was not adopted by the COBOL programmers.
One important obstacle to deal with legacy code is the resistance of many managers who believe that computing theory is not for “the real world”, just maths for nerds. I am sorry for them, but thanks God, now I am away of that “stimulant” business culture.
I did an article on programming languages being too complex in January: https://medium.com/@chasrmartin/are-programming-languages-too-darn-complex-ebb5358d8daf
And Dijkstra *was* arrogant. He was also often right.
Educate yourself. COBOL 2002 added recursion and syntax for getting and freeing storage.
Dear Sam Hobbs,
That was in the 80s, even COBOL 85 was not yet widely used. At that time some COBOL implementations allowed recursive calls. I wish that I were young by 2002 (maybe).
In that paragraph I said that the records and renamed (variant) records are something good in COBOL, even if it lacked recursion and dynamic memory by the time I learned it.
I also knew of parsers written in COBOL at that time. It is possible to do that if you know the theory behind compiler construction.
That is something that an educated (in computer science) programmer can do, because he knows how to implement recursion in a not recursive language and many other things that those programmers which were experts in other domains (in finance for example) but were hired as programmers by just learning to code COBOL (or any programming language).
That happened during the “software crisis” when there were more computer installations than programmers in the schools learning how to develop systems.
I admit that I am too nerd to tell a programmer the design errors in the programs. They take it personal reacting just defending what they did, instead of learning better ways to do their job. In the begin of 90s I had to deal with legacy code and the programmers didn’t want to learn better ways to do their job. I designed with a good programmer who was open what now is called workflow, that emerged from what I knew about Petri nets and the need to automate processes. We build a prototype but that project was canceled and later I saw a system based on our prototype developed by an external company owned by a friend of one of the managers who voted against our project. With just what comes in no more than 10 pages of the famous wizard book, that we discussed very enthusiastically he wrote a COBOL program generator, the managers how felt that we were a danger for their position (we were not because our boss wanted to open a new department) told our boss that we were discussing all the time and separate us in other jobs.
But that is not an isolated story, many programmers feel that a way to keep their job is to be the only guy who understands his programs. There are many unmoral people everywhere. Is a fact of life, so I always try to avoid such environments.
I believe that the problem is not COBOL per se, as I said, the OOP is worse when uneducated programmers use it, because all think that code is self documenting. If one don’t understand it is because one is not skilled enough, not as them.
But that is false, because what we can learn about the problem that the program solves from the code is what the programmer understood and wrote (all “bugs” included). Had they first documented the program, then everybody, including them, could be able to understand and maintain each program in the system).
COBOL, the older more verbose an limited versions, encourage bad programming habits, that some people thought that OOP was the panacea to solve them. Just browse any open source repository and the majority of the development has the same problems that legacy code, mainly the lack of documentation.
Many of those programs were written by experts in some domain (for example medical imaging) who learned a language, for example Python, but the code hard to read and of course not reliable. If you say, hey your program seems fantastic but has a lot of bugs, you could improve your system if you do this and that. The most part of the time they will react furiously defensive.
And that is something negative in the free collaborative software movement, there is many redundancy, mainly due to duplicate work, but also because the majority don’t know how to split their programs in modules and many other practices that unnecessarily increase the complexity of software.
I didn’t want to offend anybody, Dijstra used the term uneducated to refer to programmers with no CS background, although CS was under development at that time, the maths already existed.
I am sorry if you took my comment as an offense, I apologize of not write clear what I meant.
I hope that now is more clear that is a fact that are many programs developed by people with no theoretical background in programming but experts in some other domain from which they solve problems writing programs in a the hard way writing code and “hunting the bugs”, in a trial and error method.
Before you tell me that there are many development methodologies and now the programmers know about them, many of those methodologies are more marketing because they lack a solid formal background and are not real helpers in software development.
I refer to the widespread methodologies that say what qualities are important in software but say nothing on how to achieve it.
I started COBOL, FORTRAN, PL/1, and BAL programming in 1968 on one of the early IBM 360/50 mainframes. I agree that most COBOL programs are hard to maintain because many programmers were lazy and believed that COBOL is “self-documenting.” However, it is still possible to read a COBOL program. On the other hand, “C” is a write only language. “C” techniques have improved a bit with C++ but are still hard to follow and are often laced with errors. I really enjoyed Ada and even got to meet Jean Ichbiah. Ada programs on a VAX computer always ran if you could get them to compile. It might not do what you wanted, but it would run. The problem I had with Ada (something I mentioned to Mr. Ichbiah) was that it could not do fixed-point math. All math was floating-point.
Back in the old days (1970’s) NCR was big in the business/banking/retail world. Almost all of the NCR computers, from mini to mail-frame, used COBOL for the programming language. I was on one of the NCR teams that insured COBOL met government standards. One of the tests I always ran against any programming language was to add $0.01 to a variable in a loop until the wrong answer was delivered. Even with 128-bit floating-point, most computers are off by a penny after only 1,000 iterations. Not good enough for banking. The 32-bit NCR minicomputer could produce the correct answer after 1,000,000 iterations.
Why is COBOL still around? For business & banking. I currently use Java because it is quick and easy. Java lets me connect to any web site and collect financial data with reasonable accuracy.
Do you remember the switch variable? Some programmers hated it and others loved it. For instance a person in a database was listed as a widower. This caused a problem because the Married condition was satisfied first. The wife appeared to be alive as far the computer was concerned. This could cause higher insurance rate or an extra tax credit. In the old days space was tight all the logical values were stored together to save space. This was probably repaired by changing the order of testing switch values. What I’m driving at is it requires a good knowledge of COBOL as others have attested to. I liked the END-IF the best as it got rid of repeating the same If/then/else logic being used over again and over again in the same code block. The inline perform which code like a for next loop instead of in a separate block is another one. These I believe were added in VS COBOL II.
Talking about bad constructs C allows you declare a variable in a for loop or putting more than one statement on a single line. These are not allowed in COBOL. From a debugging standpoint these are bad practices.
I also wondered about the recession around 2000 when the real estate market fell. Many companies and governments downsized and many programmers lost their jobs. I wondered if they became bitter and wouldn’t come to programming in COBOL again.
I have been a member of the Bcs for more than 50 years. I programmed in Cobol, Fortran and PLAN and I’ve kept adding other languages. It is pointless comparing these to modern languages. since we had to choose from the available languages. The main point is that some of this software is still running. A testament to these languages. The design of these systems is/was far more important than the language chosen to implement it. I have noticed that the languages evolve as required. The world changes so software needs be modified, hence, a need for COBOL skills.
Gosh, I had forgotten about PLAN I cut my teeth on an ICL 1901A/1902T with Fortan and PLAN in the 70’s.
> COBOL is, in a lot of ways, an antiquated, bad programming language. But for its particular domain, it’s better than anything else.
What is COBOL applicable domain? Insurance computations, paycheck computations?
No. Many modern languages are certainly far more suited for these fields of applications. Because of better way to abstract concepts, reuse code and isolate behavior, to name just a few topics.
COBOL might be well suited in areas where COBOL programs a in daily use – purely to historical reasons. Because no one invested in modernizing legacy systems. Actually, this non-investments might have been perfect business decision in terms of the cost vs. outcome relation.
Actually I’m with an organisation, which uses a NATURAL program to perform a certain task. The last NATURAL developer left the organization for his pension. And the organisation had to hire the likely more or less last 2 NATURAL developers from or computing partner – for quite some bucks.
Is NATURAL the best solution for this task?
Certainly not. Other solutions, which would’t require to run all the stuff on a mainframe would be much better suited and likely cheaper. Actually, the solution doesn’t use heavy transactional processing, a primary domain of mainframes. And ultra low downtime isn’t a issue here too.
Actually, NATURAL is the only solution for this task, because the basis of the task is simply a bunch of NATURAL programs.
Claiming ‘for its particular domain, it’s better than anything else’ is a much like ‘A screw is the best tool, if you only own a screw driver’.
Is it better for actuarial computations? No, but then the language of choice for many actuaries is APL or a variant, like A+.
A wonderful trip back in time to the start of my career in 85, learning COBOL 85! Excellent article. I had to learn new fangled object oriented programming and relational databases took the place of flat files…great stuff!
APL!
Talk about an unreadable programming language. In the 1970s, I was programming in FORTRAN IV for my dissertation, and a friend turned a whole page of code into a single line of APL code. It ran, it was fast, gave the same answers, but I understood the code only laboriously–reading a single symbol at a time–5 minutes after he explained it to me.
APL is cool, but only if you write your program on one line, and if you had a “Space Cadet” keyboard. (APL is a cousin of C, btw.)
Dijstra also criticized APL, what surprised me, because APL is very expressive, however as pointed by Mark, it is unreadable. The main sin of Kenneth Iverson was to use a special too cryptic notation, even with an special character set. I don’t remember well what Dijstra said but was something that it was too sophisticated.
APL influenced functional programming, John Backus, developed a more elegant notation to compose functional forms in FP (in his Turing Award lecture).
I agree that APL has an obscure notation but the idea to program with algebra in mind was great.
NATURAL…. That brings back memories. Worked for several years back in the late 80s for a National Rail Company that used a combination of COBOL and NATURAL. 5 years COBOL experience and 3 NATURAL. Not a bad wee 4GL as I recall, had some real oddities (ADABAS being the cause of most of them). Not touched it since, but as I recall NATURAL was distinctly more fun than COBOL.
Article rather omits CICS COBOL – which although was just using COBOL for CICS as I recall felt like quite a different beast.
Used to love CICS COBOL and I miss JCL which is weird
This article brought back lots of memories. I started working in 96 and for 4 years I worked as COBOL programmer(the COBOL programmers used to be looked down upon in the company by the non-COBOL cool programmers).
Out of 4 years, I worked 2 years in Sydney at a client place maintaining their COBOL system.
I remember, there used to be one-off requests to do some data updates as there was some issue in production. Doing a simple data update using COBOL would demand writing 400 lines of code. I came up with an innovative idea and created a “program generator”, which given a File Descriptor, would create a complete COBOL program with all divisions, Input, output.
To do any data update was to insert couple of lines to that generated COBOL program. Till date I consider this as my most satisfactory accomplishment at work.
I was forced to learn COBOL when I was at Uni in the early 90’s. It was ancient and unlovable even then, and now it is even more so. A developer would have to very desperate indeed to retrain themselves in such an obsolete language. Short-term you may make some good money, but long-term it is a total dead end.
I learnt COBOL in the 80s as part of my university degree and my final year project involved myself and three others documenting the hundreds of undocumented COBOL programs of a major mining company. With no “search” facility available in those days, this involved printing out every program and “looking” through folds and folds of paper for called routines.
One particular past programmer, identified only by his AUTHOR statement, made free-hardy use of GOTO statements. But much, much worse than this, he was completely carefree in adorning his programs with dreaded ALTERed GOTO statements. This infuriating statement takes the form ALTER LABEL1 TO PROCEED TO LABEL2 and means if you’re looking at page 34 of some program that has a GOTO LABEL1 statement, it *may* go to LABEL1 or it *may* go to LABEL2, depending on whether the program flow up to that point has encountered the ALTER GOTO statement.
That guy was lucky I haven’t come across him in the 35 years since (although being able to actually document his code which nobody in the company had wanted to do did earn us a 98% mark on our project).
The comments section is the biggest “Load of Old COBOLers” I’ve seen since the 1970s!
Just looked on CVlibrary and total jobs and found 1 genuine position
COBOL was made to be more “English like” and easier to read and program. Companies needed a lot more programmers back then, and this was one way to get more people to program.
I see no reason for saying that companies needed a lot more programmers back then. There is abundant reason to say that back then (at the time of the earliest programming languages) the need for a non-cryptic language was recognized. Most other languages use symbols for many things instead of words. Symbols make the code more compact but not as easy to understand until the symbols are learned. Both have advantages and disadvantages.
Where’s the part about making lots of money doing it? All the plees for help I’ve seen are about volunteering.
I learned COBOL at the start of the 90s. It wasn’t exactly fresh and trendy even then, but the course I took was basically funneling all its students into one company, Northern Telecom, which still used HP mainframes and COBOL. It was something of a legal scam. They were receiving government funding, because there was a national shortage of programmers in Canada, and one large corporation benefited. They didn’t have to spend money to train up their workers; the government paid.
Yes, it happens in Canada too that taxpayer money ends up diverted into the coffers of the wealthy. But it’s so much worse in the United States. I just listened to the podcast The Great COBOL Crunch. The podcasters reveal that New Jersey is in desperate need of COBOL programmers, because its unemployment assistance system runs on that language. The kicker is, they want the programmers to VOLUNTEER.
This appalls me, but I get it. The United States starves its citizens and bankrupts its governments so that the lion’s share of its wealth and resources can bulk up the already overflowing coffers of billionaires. The heartless, like Trump and its cronies, are rewarded with outrageous wealth, while people with functioning hearts are expected to put in their time and effort for FREE.
It’s disgusting. I had a moment’s thought that I could brush up my rusty COBOL and help out New Jersey… until I heard the word “volunteer.” No. Nobody should be expected to write COBOL for free. It’s not as if it’s a fun thing to do. Nobody out there, not even us “old” programmers (I’m 52), is thinking, “Oh goody, I can’t wait to dive into COBOL again.” We’ll do it, if need be, but we expect to be paid.
Y’all need a revolution, stat. I have some ideas. Let me know if you’re interested.
Great blog! That snap of the coding card gave me the willies. I remember the late 1970’s, going to the data processing department at UC on Friday nights and running those through the compilers. My final program happened to be a dating service based on input parameters. I got an A in the class, but my instructor noted, “who would use a computerized dating service?” He probably went on to create Match.com.
I saw the creator of match.com on Sharktank a few weeks ago. She sold match.com and was seeking investors for something else.
I did an entire university payroll system in COBOL back in the 90s. I am using Python, Java, and C# etc now, but I still love COBOL. It is easy to read for beginners, business people, and for someone debugging someone’s code. I would love to help if there is a need.
COBOL, the planet where an almost imperceptible dot at the end of a long line makes the difference between success and catastrophe.
The next thing you know they’ll be looking for RPG coders.
And yes, I still have a 360 Assembler manual for debugging core dumps and writing “macros”, on the shelf somewhere.
I was really good at COBOL when I worked for Control Data Corporation in the 1970s. Will they pay me enough to get out of bed and code?
I was good at RPG II, too. Wrote THE SYSTEM/34 HOW AND WHY BOOK for IBM RPG 2 in the 1980s.
Control Data … Now there’s a name I haven’t heard in a while.
Dad worked for them until they were no longer Control Data. He fixed the mainframes that CDC produced.
Great! Any idea of contemporary smart-phones (iPnone/LG/etc) vs Cyber processing ratio?
What a flashback! Reminds me why I quit programming in the 60’s…that and standing out in the rain and having some nerd dumped your pile of cards.
Goddam…another revenue stream for old school programmers!
I would be quite surprised if Dijkstra considered the BASIC language to be superior to COBOL. Yet BASIC is used extensively. The original version of Visual Basic (not .Net VB) is not a good language but got a lot of use. It is very unfortunate that IBM did not choose Pascal instead of BASIC.
One of the primary design criteria of COBOL was that it be readable. That makes it less compact. It uses words instead of symbols. That feature has advantages and disadvantages.
COBOL has been improved. I am familiar with COBOL-85; it added many improvements, including nested subprograms. I am not familiar with subsequent versions but COBOL has been made object-oriented.
I saw a news story saying that COBOL programmers are in demand and that the company “Cobol Cowboys” was crated to satisfy that demand. Well note that there is nowhere in their website that says they need programmers.
There are tools that can logically restructure COBOL programs. I do not mean physically; they can process a COBOL program and understand what the program is doing and generate a completely new program that looks very different. IBM wrote one about a quarter century ago and I know there is a competitor that had one too. I am sure that there are also language conversion programs.
The following might be interesting to some and boring to many others.
Also about a quarter century ago I wrote a program in COBOL that parsed manufacturing instructions written by engineers for use by engineers; people, not the computer. It parsed out tools and materials so they can be put into another program for use by the computer.
Grace Hopper wrote the first compiler (ever of any language) and was very involved in the design and development of COBOL. I met her but at the time I did not know how important she was. I even stumbled into her office once in the basement of the Pentagon but she was not there. I really regret not asking her for work; I am sure she would have had some fantastic work for me.
Dear Sam Hoobs,
Tha kind of tools are, among other things, what is needed to do what in the 1990s was called revers engineering, to analyze undocumented code to understand what it does.
I don’t think that there is a general way to do it, because there are a lot spaghetti code in programs written before structured programming arrived.
If you know how to write parsers, then you could write ad-hoc translators to improve the legibility of COBOL-85, commenting the COBOL source code with a more abstract notation. For example from a loop you can infer for every record in file X do this and that, and so on. Being the comments a more abstract programming language.
You have what is needed, experience with COBOL-85 (legacy code) and building parsers. Just build a translator to the simpler language.
Although I believe that it would be better to rewrite all the legacy programs in a new more concise and expressive language, structuring in a different way. A process which may be very hard or impossible to automate from legacy software.
And the common problem is that there is often no documentation of the processes that motivated the development of the programs, if it exists, it is rare that is in synchrony with the program.
By the end of the XX Century, almost all programs were structured and I expect that are more legible and have a better style, even in COBOL.
I learned COBOL, just to approve a course, in a book a titled something like Structured Cobol or something similar. The authors promoted a good programming style following recommendations from “The Elements of Programming Style”.
The OOP is not better than structured programming, it is said that it was derived from Simula-67, (a simulation language to model queuing systems and alike). Another antecedent is the Actor model of Carl Hewitt and team. But OO languages grew to much in complexity adding features that complicate them. See how bad were implemented lambda expressions in C++, contrast it with how easy is to implement OO in Scheme (in the wizard book). The lack of simplicity is a signal that something is wrong.
It’s a common misunderstanding among COBOL programmers that all that code is still in use because it is so great. Rather the opposite is true, because it is so opaque and unstructured it’s been impossible to upgrade. It is also cash-cow for the vendors of main-frames that appreciate the enormous lock-in.
A well-structured COBOL program is a beautiful thing. I spent almost thirty years using the language under three different mainframe vendors (IBM, Honeywell, and Siemens) and can assure you that it can be perfectly well structured. It is not the language’s fault that aimless programmers used its ease of coding to produce rubbish code, impossible to follow, that nevertheless worked.
And don’t forget that sometimes the programs were compiled, and the source code (cards) lost. That was a major problem right before Y2K.
“if you’ve been told that it takes 90 lines to write a basic program in COBOL, well, you’ve been misled.”
That is absolutely true. As we see it only takes 5 lines to write Hello World.
It takes 90 lines of JCL to get it to run.
I once worked in the financial sector, though I never used COBOL myself and I’ve made it a point not to learn it, mainly because I didn’t want to work in the domains where it’s used. — It isn’t just that COBOL is “not cool enough”, it is also that the Workplaces that use it tend to be stuffy, with some concept of “professionalism” that is as old as COBOL; you must wear a suit to look professional, formality is professional, familiarity is not, “fun” is “unprofessional”.
I’m almost as old as COBOL myself, and those ideas of what it meant to be “professional” turned me away from applying for quite a few jobs.
The workplaces that are like that would likely be just as oppressive and joyless if they were using modern systems and languages, and *that* is another thing that makes it hard to hire people to write COBOL.
The word COBOL, brings back old memories. I used COBOL with a Hierarchial DataBase within a computer graphics mfg environment on a DEC VAX/VMS 11780 and 8600. It’s a good language, but a little wordy. But it can be done, if needed. In working with COBOL, we combined PLI, “C”, and fortran and a lot of 3rd party packages.
‘Computer Programming Made Simple’ is 90% about COBOL and covers every aspect of the language
You can teach somebody to write a computer program but you can’t teach them to be a programmer. You either have it or you don’t. I first trained on IBM Mainframes in Assembler and COBOL in 1969 and still use the latter occasionally today for retrieving data from an archived legacy system.
A “good” COBOL programmer can write very elegant code that is easy to follow and easy to maintain. One of the things that made it more difficult was the extended use of “includes” and “copybooks” that resulted in it being very hard to follow the logic of a program. COBOL’s verbosity would make it more time-consuming to write but, if well-planned and well-written, it would require a shorter time to error-free production than a lot of the modern tools. And it was a much more powerful language than it is given credit for – there was very little you couldn’t make it do.
@Christian – if you have not discovered it by now: Success in coding is not about which language you code in. It is about your ability to build solutions that solve problems. If you are not a problem solver, you can pick any language and you will not cut it.
First time seeing COBOL and i like it already. It looks like STEPS to execute an ACTION a.k.a algorithm. Statements like we used to write in High school to execute a certain task before going on to the computer to run it (nostalgic). To those who are taking a Swipe at the language, there is a always the best tool for the job (An excellent programmer knows this axiom). If you don’t like the language it means you can’t do the job and If its not good for you, it does not mean its not good for the objective at hand.
spot on
Every once in a while someone will write an article about how there is a desperate need for COBOL programmers.
Until one asks “Who is hiring?”
Crickets.
There is no need for COBOL programmers.
Many large companies with huge commitments to old mainframe technology have done the math and discovered it is more cost effective to just run the mainframes rather than convert.
COBOL code represents the codified requirements for a business or government. Basically the fundamental rules for the organization on some pretty important processing. So the COBOL code is the collective wisdom of large organizations.
Crickets indeed. As I stated I always tell recruiters that send me COBOL jobs that I will be happy to work part time remote flex hours to supplement income.
The answers….. NO NO NO this is full time only. I just say OK well good luck then.
Wow, that is truly a blast from my past filling out those cards at university and later, programming COBOL for Chemical Bank in London (IBM System/36) in my first software development job. I was pretty good at it too. If someone wants to pay silly money to get me back, no problem !
I have been working with COBOL/400 for OS/400 for may be 25 years. Different from many comments here. I do not want to judge whether it is good or bad. I just want to say it is just a programming language with its own uniqueness. I also work on Java, Javascript, c++, C#. I work with spring boot, angular. For me it is not about the programming language. But it is about whether you are basically a software developer or not. If you are, the programming language is just a tool for you to express your logical thinking.
Of course I agree that modern programming language like Java or C++ can facilitate object orientation development but solving a business problem can always be done whether using COBOL or using other programming language.
Until today, I have no problem handling IBM iSeries, OS/400, COBOL/400. Retrieving the data from the IBM iSeries box and present it out as a web. I am used to mix COBOL with other programming language and environment.
In Chinese there is a saying, black cat or white cat, as long as the cat can catch a mouse is a good cat.
Hello, as a COBOL programmer, ages ago,I’m surprised about this article. Remembering my dealing with COBOL writing sheets, it is really strange that programming tool has not been developed to make an easy interface between the programmer and the real COBOL code writing … at least AFAIK… at Argentina .
As a retired Cobol programmer I can tell you that it is an excellent language. It’s main advantage is its commands are self-documenting. Each line is easy to learn to recruit new developers, unlike C# for example. It also solved problems decades before others, like database data integrity. Many ‘newer’ advantages where first in Cobol, like modularity.
“As you can see from this little example, COBOL is not like your normal programming language. You can’t write a compiler or a kernel module in COBOL, and the syntax is not what we’ve grown to expect. But then consider another common domain-specific language: SQL. The syntax is kind of weird, and the semantics depend on relational algebra.”
Well, blow me down. Seeing COBOL and SQL in the same sentence is hilarious. I was writing in COBOL using flat files long before databases were common, and it WAS the ‘normal’ programming language, unless you were skilled in Assembler. COBOL worked well for what it was designed to do, and the worst thing about COBOL is that people with little or no skill could write it – and did – lots of it. On the other hand, SQL is not , as is COBOL, a ‘common business’ language. It’s a data-manipulation language, which is what IT is designed to do. Unfortunately, lots of people with little or no skill write IT also. SQL is excellent for what it is designed to do.
You make a great point. I’m a college student in my senior year, and when I was introduced to databases and SQL I was so surprised by the formatting and verbosity. It seems very easy to make lots of mistakes (delete Customers; with no where clause comes to mind…) if you just pick it up and try to code without actually learning the language properly. I myself am not a fan; I started with Java and my favorite is probably C++ (feels more flexible). My older brother works with SQL frequently and it obviously has its uses.
We used to write COBOL with SQL. IBM 3900 with DB2 database.
I took a COBOL class back in the late 70’s as part of the degree program in college. After destroying hundreds of punched cards due to typos. I never wanted to use it again (I am not the greatest typist and the punch card machines at school were over used). The one good thing about COBOL is that it was so verbose, it practically commented itself. A few years ago I had to support a lab application that ran on SCO UNIX and was written in COBOL. The creator of the application thought COBOL was great
Well I can still look at COBOL code some 15 years later and remember just about all the parts. I coded it for over close to 20 years after all.
At Buffalo State College in Buffalo NY we were learn Assembler, FORTRAN and COBOL. ISAM files then VSAM and this new relational data
thing called DB2 that hit market in my Sr. year and which only came up in theory. In my legacy career I added DB2, CICS (with Assembler maps),
report sections (that came and went), IDCAMS, IEBGENER, DBRMs. LIBRARIAN and other source control tools. Got super excited when this
Microfocus COBOL tool showed up. Full GUI Workbench and FTP options for moving code to a PC and the mainframe. Goodbye stupid green
screen editor. Microfocus for Unix and hello Oracle. Then I caught the object oriented bug and went Java, .NET web apps and never looked back.
Well not entirely about 5 years ago I jumped back into Microfocus but I soon realized how going back and accepted limitations with tools was not fun.
I keep sending notes back to recruiters that send me COBOL jobs. I tell them I’d be happy to do the work part time remote with flex hours.
Sort of as a supplemental income. Can’t get any of them to budge. Its all or nothing. I envisioned converting tons of COBOL legacy to other
architectures but to my surprise that only happened in a few contracts. I’d love to help out with some of the companies still using the language
but those darned gate keepers built an impassible moat to the castle.
The problem with COBOL isn’t COBOL. The problem is that COBOL applications tend to involve a mainframe environment. I seem to recall a mainframe programmer friend of mine (25 years ago) telling me the key detail was to avoid ever working on the mainframe when possible. (I don’t work on mainframes so I don’t know what that includes other than editing source code “outside” the mainframe.)
DYNALLOC=SYSDA anybody?
COBOL isn’t “suddenly” in demand. Most of the government’s mainframes run with COBOL programs, and they’ve needed programmers on a fairly steady basis.
For instance, ten years ago, my uncle took COBOL so that he could program the machines. Of course, he also had security clearance, having served in the navy for 30-some years.
I’m still waiting for the day that Plankalkül makes a comeback. It had some features that didn’t show up in mainstream programming languages until decades later, and could be written in a one-dimensional or two-dimensional format.
“if you’ve been told that it takes 90 lines to write a basic program in COBOL, well, you’ve been misled.”
is actually incorrect unless you’re talking about “modern” COBOL. COBOL of the 60’s, 70’s and early 80’s did have a lot of extraneous cruft that if not properly added and in the correct sequence would make nothing but large amounts of compiler output about why it doesn’t work.
COBOL is a wonderful language if you look at it correctly. It’s highly memory efficient and the code that you enter is very easy to compile into efficient machine code. Obviously that’s one of the reasons why it’s structured the way it is and why you have to code it the way you need to. Compariing traditional COBOL (<1990) to almost any modern language (C#, Java, Python, etc…) the compiled output or COBOL will be almost a single digit percentage of the equivalent code in the modern languages. WIth the additions of so many things to COBOL since, the 90's it has become easier and more difficult to get the basics done when comparing to the more recent languages because most of the "cool" libraries are not available for COBOL. Also remember that bad developers are can write bad code in any language. A language that allows for GOTO and PERFORM-THROUGH can be horribly misused and show the original definition of spaghetti code; couple this with a language that uses "short" lines, "hidden" periods and is vertically verbose it makes for a distressing workplace if you jump into it now with "modern" ideas on how things should be done and expectations around what an IDE should be able to do for you.
A thing to remember about the companies that need COBOL programmers now is that in many cases the code they are attempting to support is written for an older version of COBOL, which means some of the more useful constructs aren't available, hence extra cruft was needed to accomplish "simple" things. Given that a COBOL compiler's lifespan is measured in decades, this makes for a fun time (see above for a comment about when "END-IF" was added, try coding today without using END-IF!). It is also common for COBOL consultants to write "bad" COBOL code so that only they can fix it; now this isn't a new thing in the consulting industry, but in a niche market like COBOL the competition can be fierce for almost non-existent contracts (depending on your pricing requirements).
Knock COBOL all you want, but does your language have anything that's been running for 30+ years and the language and OS still supports the original code?
@Charles Thanks for taking the time to include COBOL in this blog.
From a quick glance there are two issues:
1) What’s your reason for the Broadcom plugin? I’ve spotted nothing you actually use it for and you explicit say “this is about COBOL not the mainframe environment” (I definitely recommend the bitlang.cobol plugin).
2) You wrote about GnuCOBOL “Honestly, if anything is going to cause trouble, it will be this”. What is your reasoning behind it? With a current GNU/Linux distro which uses apt: `sudo apt install gnucobol` on Windows just download the official ready-to-use binary packages from https://www.arnoldtrembley.com/GnuCOBOL.htm and you’re ready.
My big success in COBOL was to have one of my suggestions included in one of the proposed standards (either 1985 or the one after 1985).
It was to allow file connectors to be passed as parameters. I was one of the few people at my employers (uh, let’s just say “back then”) to actually build COBOL subroutines, in this case on the H-P 3000 platform.
My earliest exposure was to “modular programming” and Fortran, and as I recall, that was followed by “top-down programming”, “structured programming” (largely in COBOL), 4GL, OO, RAD and now “agile”, admittedly with some blurry distinctions among those.
I’d rather stab myself in the hand than learn COBOL. I’ve avoided it for over 25 years, since I don’t want to stagnate my career more than I did by working on VB Access/5/6/.Net/Script projects.
“Oh, but you’ll be making +$200k a year.” And never, ever work on another project in my life. No thanks. And yes, that’s the argument I’ve heard for the past 5+ years to get into COBOL and even FORTRAN. I’d rather not continuously punch myself in the face every day.
Companies and governments just need to replace their primordial software with something, nearly anything, written in at least a semi-modern language. This seems like the arguments between an old-timer (“In *my* day….”) and those that want gramps to learn how to use a smart phone while giving up their wall-hanging phone.
In the late 80’s I used Turbo Pascal to generate the COBOL code I needed to pass the college COBOL course.
How about using a current picture of a IBM Mainframe, like their new z15. The z15 is contained in a standard 19″ rack cabinet and can be expanded up to a total of four frames. Details at https://www.ibm.com/products/z15
Ok, I am confused or maybe it’s a cruel COVID joke. Where are all those promised job postings? There are literally thousands of experienced COBOL programmers looking for work.
https://community.openmainframeproject.org/c/calling-all-cobol-programmers/
Why would I spend my time learning COBOL (which by the way seems easy enough), to put myself in the category of thousands of experience COBOL guys. Makes no sense.
The language is not the issue (It never is for any programming by the way, since the difficulty is the custom libraries, environment frameworks).
Would appreciate any ideas, about whether even I go through the udemy or other classes. I mean, you need to mear JCL/TSO/DB2, etc as well. What are my chances of getting a job? I have years of experience programming and tech with Linux and not afraid of green terminals :).
Wow, its been a few years and yet yet I can still read that code and tell exactly what it is doing. Brings back the day I debugged a 250+ page printed procedures a teammate wrote.
Given all the challenges of finding qualified people that keep popping up perhaps the focus should be on converting from COBOL to some new language for the future. The biggest challenge would be finding someone who is able to move from a procedural language to an object oriented one and yet be good at both.
My first comment ever,any blog, however this deeply touches my heart. I have 30+ years experience in COBOL, DB2, JCL, CICS, VSAM, Easytrieve, Syncsort, Xpediter, etc. I have worked in Java, C#.Net, Oracle, and SQL Server. I have taught VB.Net and C++.Net at local colleges. I have been a team lead, technical lead, and project lead.
I have written 10000+ line programs with dynamic calls, 25 output files, and XML. My contract couild end in a month so I am desperately looking for a position and there is practically NOTHING available. Contracts are short term and do NOT pay $200k. If you are doing $100k consider yourself lucky. They want you to know obscure software packages that you would only know if you already worked there. Or they want you to be a Cobol programmer who also just happens to be a CICS administration guru. Sorry to vent. Just worried about the family. How long have I been looking? Over 1 year. 3-4 hours each day. Not lying.
So how does one get back into cobol/mainframe. I have +20 yrs, but I’ve been out 7.
i completely do not agree. I am not sure what is your experience in Cobol because u only describe simple hello world . there are not many libraries that is the problem. It very depends if Business understand what language do they need. Or maybe Cobol is only used for integration because other part of code core parts were written in Cobol. So testing is the most important We are happy to audit that code and help. There are reason why Cobol should be still maintain because there is so much logic in Cobol and no one would like to guaranty that new code will be working
Great article. I enjoyed many years as COBOL developer in telecoms and finance. It’s very easy to relate the language to real-life business ‘objects’ without the overhead of an OO language.
It’s often forgotten that Mainframes are still preferred for their immense processing power, reliability and scaleability. They will be around for many decades yet, as will COBOL.
I’ve programmed in many ‘modern’ languages, but give me COBOL and C over all the others anytime.
Jan Myrhaug at the Norwegian National Computer Centre famously wrote a table-driven compiler in COBOL in the 1960s.
Hey guys I’ve been coding Cobol and JCL since 1973. Anyone remember Easytrev or U.F.O (User Forms Online). How about VSAM files and of course the dreaded core dump.
I wrote Structured COBOL for 20 years. Never used the dreaded GOTO, never used EXIT at the end of the paragraph and just like your examples, I put a period at the end of the paragraph and nowhere else (COBOL 85). Used the END-
I’m neither a COBOL or Java programmer, but in regards to the hello world example there, I’d much rather type characters than tabs, braces, brackets or whatever symbols that seems to be much needed for Java. It’s also far easier COBOL too, at least in this example.
This article is definitely a worth reading. Initially in my career when I was working with Accenture, I have used COBOL for the mainframe projects. But later moved to Java and now working in JavaScript.
Hi all,
I have started my career in the beginning of 1975, guess what, using COBOL in IBM Mainframes (OS/360, MVS/370, DOS/VSE, XA/390, z/OS)!
Although I have been an Analyst/Prog, DL/1 DBA, DB2 DBA, Team Leader, Proj Manager, I eventually returned to programing in COBOL about 10 years ago and love it!
I have learned other languages like C, C++, JAVA, Python, Pascal and recently did a few courses on MongoDB.
I am looking forward to end my career in 2025, so I can claim to have worked for 50 years and almost my entire career in IBM Mainframes!
To all out there, the important thing is to be doing what you like and enjoy it.
Keep going strong.
Rui Praça
I started in computers as an IBM360 operator for NASA and moved to programming, analysis, system design, architecture, management, security and disaster recovery. Yes, I was a great COBOL programmer. My last project (10mil lines of code) was written in JAVA mixed with a hodgepodge of vendor software. The detail design, coding and implementation was a complete failure. Experience has shown JAVA is a very poor language for business and hard to implement on a large scale. JAVA is an undisciplined language lending itself to lose, uncontrolled and very difficult to maintain code. Worse, schools today don’t teach the basics of computer processing, program design and quality coding. Thus the quality of JAVA programming is less than one star. This why todays systems keep failing. COBOL may be old but it forces design, programming and coding standardization. Lastly, I don’t get where academic types who never coded a day in their life get to decide if a computer language is outdated. using their logic Disk drives S/B outlawed and died years ago after all, the disk structure standard was developed in the 1950’s.
Using Micro Focus COBOL, the sample “”Hello World” program code may be simply coded as “display ‘Hello World’. No more!
🙂
COBOL is one tool in computer world. Like Spanner for Nuts and Bolts Just because it is old it cannot become good/bad/ugly. I believe people still use Spanner and use it manually. Spanner is older than COBOL :-).
I happen to work on C programs which generate COBOL statements ( Embedded SQL Support for Cobol language). Till date the product is alive. We could mange it work with all C Libraries seamlessly as other language programs. Even the memory address also by calling a one line C function to return pointer to calling Cobol program ahead of actual C function call.
COBOL is Computer Programming. It is the mainframe which has the result-oriented book that is the same as Computer Science’s architect and integration distinguished definition. Rephrased to the article by greater number and void calculation explained fact, I see that how it works out to be unsatisfactory to be a computer programmer when people see is stats. Coding was such a disastrous powering boiler-plate when circuit is accumulation. Maybe that’s because in mathematics there is Boolean.
I’ve done COBOL in the past (on an IBM System/3, System/34, and System/38), not in a log time though. I’ve also written in various BASICS (starting with VS/BASIC on an IBM S/370 then Altair BASIC, and Microsoft BASIC for CP/M, up through VisualBasic and VBS). I’ve done C, C++, Perl, PHP, AWK, SED, Forth, Pascal, and various assembly languages (M6800, 8086…). I’m currently using JavaScript, python and… RPG.
I’ve done COBOL in the past (on an IBM System/3, System/34, and System/38), not in a log time though. I’ve also written in various BASICS (starting with VS/BASIC on an IBM S/370 then Altair BASIC, and Microsoft BASIC for CP/M, up through VisualBasic and VBS). I’ve done C, C++, Perl, PHP, AWK, SED, Forth, Pascal, and various assembly languages (M6800, 8086…). I’m currently using JavaScript, python, and… RPG.
RPG, like COBOL is a business language and like COBOL it has fixed point (i.e. Currency) numeric values by default. Also like COBOL, everyone hates it 🙂
But like so many other things, music, art, literature, and programming languages, people will hate what they are unwilling or unable to understand.
COBOL is not my favorite language. That doesn’t mean I think it should not be used, just that, personally, I’d rather use a different tool (again my tool of choice for business programming is ILE RPG on an IBM Power i)
I used to sit on a code-review committee and there were frequently Java programs being presented using floating point for currency values. This was at an Insurance company where things HAD TO balance. Floating point was wrong in this instance. Was Java wrong? Not really. But if you thought in COBOL (or RPG), you’d think fixed point with no rounding errors and code correctly. So learning COBOL wouldn’t have been “criminal”.
My feeling is that you should equip yourself with as many tools as possible. Even if the tool isn’t available on your particular platform at a given time, you can THINK in the tool and then CODE in whatever you have available.
As it’s writen COBOL is a specific usage programming language. By the time it was build, it was created with the technical limitations of th system it was meant to used on. And also with in sight the need for the most money cost efficient way to do things, and deal with data.
And to do this, the users (bankers, financials, and data business) had to deal using automated card managers machines. With the birth of integrated electronics, and with some other fundamental creations (electronic components and data storage), with downsizing of machines, data could also be stored on magnetic tapes (and soon after on hard drives). Then it became vital, and urgent to create a way of dealing with paper data cards, so with a simple to read program, you could worked with databases.
But the machines were kept on old compute way of doing things. So they build COBOL in a way so the place of each hole on cards had the same meaning has on paper data cards. And what was seen as a beautifull creation, was just a lazy way of doing things.
Besides that, a few big companies made their way so they were the only ones who had the lawfull right to do any change/evolution over this system. First of all was IBM, which had (and still has) one of his biggest businnes partner which is SAP.
And together, with the help of financial/banker industry, they kept COBOL over 60 years as an old, ineficient and ugly programming system.
You said it, COBOL can’t do dynamic memory allocation. It’s really complicated to do recursive data treatment. And also, it’s kept in his old way of doing things.
When the C language was created (some years latter, I agree). The creator of this language, accepted that it could be just a base, and could have further evolutions in it’s writting. Then, an evoluted version of it was made C++, and after that C#.
But about COBOL, it was kept in it’s restricted and limited users. It was never spread outside of their circle, so it’s said (by their makers) that it’s a fully secured programming language. Which is a lie. What makes it partially secure, is his little access to the coding world.
So when it’s said, here and there, that COBOL is a language that will never die, you can say the same about latin, or Linear A. The problem is that fewer people continue to use it, and for the Linear-A (one of the oldest written language), there is nobody twho can understand it, because all the civilisation that could spell and write it is dead for long.
It’s the same for COBOL, it’s old, it’s just a constraint usage language, because for their users, it’s easier to maintain it, than making a migration of their programs. But it’s not saffer or a secure way of doing things. It’s just because the coders are lazy, and their boss greedy.
And it’s the same about cryptography. I found a way of craking RSA key system, in a way it’s not necessary to test statiscicaly the best keys, but using a linear way of building the private key, using the public one, and knowing the size of the primal number set used to create them. It’s not that hard. And I’m just fell the maths licence exam in the last year.
So if you want COBOL to be language that never die, then you have to accept evolution, or it will die, and sooner than you can think.
Interesting for new learners. Never thought that COBOL is so old.
When I was learning to program, in the late 80s, we studied only COBOL, and I did some COBOL programming. I decided personal computers were the future, so I focused my skills development on object-oriented prgramming, and client-server platforms.
I did some professional COBOL work but most of my exposure to COBOL was accessing COBOL data structures with more modern programming environments.
One thing not mentioned in this article, but which is extremely important, is that just learning to code, or even to program, in COBOL is just a small part of the job.
The mainframe environment is unique to each organization.
When outsourcing became a thing in the 90s, the mantra was “You don’t need to be a techie to manage techies”, and IT management was taken over by analysts and bureaucrats who did not have the technical expertise to keep the more esoteric parts of the platform going.
When outsourcing took over in the late 90s, an awful lot of instituti onal knowledge walked out the door with those IT pros who had been at the companies for ten years or more. The routine coding could be done by newbies, but a lot of advanced knowledge, both technical and organizational was also lost, not to be recoovered.
One of the things that happen over the lifetime of something like a payroll program is that data forms change.
An example is that payroll systems used to keep track of veteran status, or educational levels, and originally had little or no racial information.
Over time, the same spaces on the record had their meaning changed. also, the codes changed over time. Very few of the places I worked had good records going back decades documenting these changes.
A common practice of programmers was to comment out obsolute code, rather than replace it.
So a programmer going in, twenty-five years later, may have to go through thousands of lines of spaghetti code, trying to figure out what was relevant, what was wrong, and what was obsolete. Not a trivial task. And one not respected nor understood by bean-counters and politically-connected upper managers who were in charge of the department.
I’m surprised it has held together as long as it has.
Cobol is a language for business. It is not for general purpose language. It is structured language. It has a top-down approach. You can’t break the flow. It has only one way. Before you write your COBOL program, you need to work it out in flow chart. It is a language that is used for Banking and it is good for the people with Accounting and Finance background. Compared to todays language it may look out dated but it is not very easy to replace with other languages. That is the reason it is there and I believe it will be there for very long time.
I learned COBOL in 1995 and it was the first programming language at that time I learned followed by C on Unix. Flowcharts were common at time before coding. I really excelled at it and was very good at it. There weren’t many mainframe jobs in India at that time as India was not economically as big as it is today at that time.
People shifted to flat database like DBASE and FOXPRO which were cheaper to install and then to Oracle and Sybase .
I have worked on all these and adopting to new software like html, javascript, business intelligence and phyton and more.
I still believe COBOL is very unique language and it very difficult to find that will take it place.
I studied COBOL in the late 1980s. It was not considered bad or crap in any way. It did what it was meant to do and it did it well. Young spotty nerds that play with C++ or Python make comments that they are not qualified to make. In 2000 I was offered a huge salary to rewrite COBOL code to allow for the year 2000 bug.