New research aims to analyze how widespread COBOL is The Open Mainframe Project's COBOL Working Group is seeking to discover just how much the venerable programming language is still being used in the industry, and it would like your help. Yes, the Common Business-Oriented Language may be over 60 years old, but it is still widely employed and continues to play an active role in …
The database designed use by for COBOL programs was IDMS(X), not SQL. Technically it was a CODASYL database, but these days we'd call it an 'edge database'. However, SQL got grafted on later via a defined set of standard procedure calls.
The IDMS/CODASYL approach added two extensions to COBOL:
- one was a data definition preprocessor which translated the database definition into a set of COBOL subroutines which were compiled like any other COBOL subroutines
- the other was a language preprocessor, designed explicitly to act as an extension to COBOL. IIRC it didn't add or require any additional data types but, instead it extended COBOL by defining a set of database manipulation verbs. The preprocessor replaced these by sets of standard COBOL statements and subroutine calls when it was run: the resulting output was 100% standard COBOL and so could be compiled by the standard compiler.
Compiling and then linking the code output by the language preprocessor with that output by the data definition translator produced an executable object that could access and manipulate the database content, but was the result of compiling 100% standard COBOL output by the two preprocessors.
I thought it all worked well: the DB designer needed to understand the DDL syntax, but the additional knowledge needed by programmers was minimal: just half a dozen extra data access and manipulation verbs which they found easy to code for, because these behaved more or less like any other COBOL data i/o verb.
SIDE NOTE: I though it was interesting that DEC's initial relational database offering on the VAX did something similar. It didn't implement SQL, instead it used 'database procedures', which were very similar to SQL procedures, though they were separately compiled and linked procedures rather than interpreted code.
IMS (a hierarchical database, as well as a transaction manager) was released 7 years before IDMS. System 2000 (a hash database) was released 3 years before IDMS.
IDMS (and CODASYL) was certainly important, but it wasn't the first DBMS used extensively with COBOL, nor the first with features designed for use with COBOL.
These days, a number of COBOL implementations still include database-operation verbs, though they're not part of the standard language. The most prominent is the EXEC SQL macro facility, which of course is SQL, not one of the older database technologies.
"Isn't SQL just COBOL for databases?"
Sort of; [original] SQL is RDBMS for Cobol programmers.
SQL is a relative late-comer to the RDBMS field. Before it were things like QUEL on Ingres, which I used from around 1981; my QUEL manual is dated 1977. The original SQL was rather lacking in functionality and did not implement the full relational algebra. The lack of functionality was because Cobol programmers generally did not understand things like data types and recursion. (CS courses at university were a very new thing at the time.)
With the passage of years, SQL has become more capable, but also more baroque. No two vendors implement the same syntax, and where they do overlap they frequently have different semantics. This lack of standardisation in both Cobol and SQL has paid my wages for a good may years ;-)
And still can be. There are currently 19 possible values for the DIALECT compiler option. And then there a number of compiler options which tweak compilation and runtime for various aspects of compatibility, such as character set and fine details of how numeric types behave and other aspects of the language left to the implementation – including how recursive PERFORMs behave, for example.
(It's "Micro Focus". Two words.)
> Isn't SQL just COBOL for databases?
As already mentioned, nope.
What they do have in common is that the designers of both COBOL and SQL had a requirement to "make it appealing to non programmers" (or words to that effect) by making it passingly similar to normal English prose.
Very passingly, I would say fleetingly, similar, mind. But someone sometime somewhere must have thought that was a good idea.
Just saw off the last little nugget of COBOL lurking in one of our 25 year old systems only 6 months ago! It was fight to pry it out of the user's hands until we handed them something with a sticker on it that read "Runs in the cloud!" and the PHB's couldn't dump the old system fast enough!
I started with Basic and Assembler. Then I went to Uni and got taught Pascal.
When I left Uni, all the best IT jobs wanted experience in C++, so my first job ended up at a bank writing IBM mainframe COBOL.
After hating COBOL for a couple of years I began to appreciate that it was actually pretty much the perfect language for our application. Yes, it's boring, but business processes are similarly boring.
If you can write nice clear simple code, you can't really go wrong (although somehow a lot of people managed to do it very wrong). It's remarkably easy to write a piece of code and have it work perfectly first time. Most of the problems came from people trying to be clever and introducing unnecessary complexity.
If COBOL had not been created back in those days and it was created today, then everyone would be running around saying that it's such an easy to use language ... so much easier to use than Rust in the banking world.
Created these days it would be our Cloud Organized Business Oriented Language.
Cloud Organized Business Oriented Language
... in which you have to have a subscription to use certain data types.
So, with the Cloud Organized Business Oriented Language Basic package you can use int and char,
but if you upgrade to Cloud Organized Business Oriented Language Professional you get to use float and string.
Isn't that a great deal?!
Oh, definitely. As OP wrote, many people do manage to get COBOL very, very wrong.
There are certainly historical infelicities in COBOL. Separating declarations from procedural code turns out to have been a Bad Idea, for example. (In MF Managed COBOL, you have the declare verb, which lets you do point-of-use declarations, as well as things like type inference; it makes the code so much more readable.) Lack of parameterized paragraphs/sections is definitely unfortunate; you can write every routine as a separate "program" (callable procedure), but pretty much no one does. COBOL-85's scope terminators (END-IF, etc) are a huge improvement over pre-85 sentences, but older code and a lot of newer code doesn't use them.
But the main problem I see with most of the COBOL I look at is that the programmers just didn't much care about readability or maintainability. And that's true for the code I see in pretty much every language. When you're working with a highly-expressive language with a lot of syntactic sugar – OCaml, say (or F#, which is basically fancy OCaml for .NET), or Scheme, or even Javascript – there's really no excuse for not writing highly readable code. But if what I've seen over the past few decades is representative, most people don't.
IDENTIFICATION DIVISION.
PROGRAM-ID. TUATLTUAE.
AUTHOR. DNA.
PROCEDURE DIVISION.
DISPLAY "Forty Two".
STOP RUN.
Remembering happy days trying to get HHGTTG references in my code sheets past my System Analyst. I suspect there are still some accountancy programs acredited to Zaphod Beeblebrox lubricating various government systems around the world.
... (and its a lot older than COBOL)
We get so carried away with our Languages du Jour that we forget that COBOL is a way of automating already documented business processes. These processes might have already been partially automated using eletromechanical tabulators and sorters. It does this job brilliantly which is why it has endured for so long.
There's lots of things I wouldn't dare try to express in COBOL but then its straightforward to interconnect programs and processes. "Horses for Courses"
IMO there's a name for a computer language that tries to do everything for everyone. Its called "A Mess".
I have a colleague in his mid-40's whose retirement plan is to become a Java-grandpa like these COBOL-grandpas, so that his retirement days in 2040's will every once in a while get interrupted by invitations to work against a three-figure hourly wage when some big corporation needs to change anything in their enterprise Java software systems that these modern javascript kiddies can't just comprehend.
Java is already the new COBOL. They're both overly verbose languages designed so that legions of barely competent corporate code drones* can work on code without shooting each other's feet too much. As such, giant corporations have invested so much money in it Java that it'll still be clunking along decades from now (and a lot of 'newer' languages run on the JVM) - I think your colleague has an excellent plan.
* There are some awesomely skilled COBOL and Java programmers - but they are not the target market.
COBOL's great strength is its ability to model number fields exactly how you want them. Need something that can go from 0 to 9999.9999999 (but not negative)? Easy with the right PIC clause. No slumming it with inaccurate Floats, or bignum integer work-arounds.
That strength alone (and yes, COBOL has many weaknesses) has kept it a contender in the financial arena.
COBOL was more widely available, so there was more existing code and more developers who knew it, so shops preferred COBOL. It's the same positive feedback that we see with many other programming languages (and many things unrelated to programming).
Our current COBOL and PL/I offerings have many of the same features and play together nicely, but the COBOL business is considerably larger than the PL/I business. There's simply less PL/I out there.
Also, COBOL edited-numeric picture clauses go beyond what PL/I will do for you, though how much effect that actually has on language productivity remains to be shown. There are plenty of ways to do fancy numeric output.
As far as I know, there is no other mainstream computer language than COBOL that can do the equivalent of the following rather, commonly used, numeric formatting:
77 ACCOUNT-BALANCE ZZZ,ZZZ,ZZ9.99DB BLANK WHEN ZERO COMP SYNC.
as a single variable declaration, or, for that matter, in any readable single line of code.
Yeah, pictures... fantastic!
The more I'm thinking about the more I want to take a pencil to sheets of paper organised into 80 columns! (Which, possibly sadly to some, I know I have in the proverbial attic!)
A few years ago I considered revisiting COBOL for legacy systems, hmmm! That, and Clipper, a language I like a lot, with lots of lines out there - not to COBOL levels obviously, tho!
The COBOL 90 spec relaxes the line length and column location restriction to allow freeform code, so most of the current compilers no longer require the 80 column restrictions.
To me, what's interesting is the attention paid to backward compatibility -- programs written to COBOL 66 standards still compile and work correctly in 2022 WITHOUT change. Ain't broke, don't fix it.
It's also interesting that HBCU's (historically black colleges and universities) are investing heavily in teaching this tech to students -- guaranteed jobs for their grads.
Thanks for the info regarding column locations, I've not looked at COBOL for a long time. Makes me sad though, because I'm a total advocate for code indentation! (Yay Python!)
I guess HBCUs are a US thing? And further guess that you're implying that those excluded due to ethnicity now may, in the future, be included in greater proportions due to this training. This makes me even sadder, due to the necessity for the approach, not the inclusivity. Talent/ability > ethnicity/gender.
True, but with the caveat that, given the appropriate class definition, any OO language can.
“Smalltalk“
accountBalance := AccountBalance new.
//Java:
AccountBalance accountBalance = new AccountBalance();
And, having written that, I suddenly remember why, as a Smalltalk devotee, I find it easier to understand why one could be a COBOL aficionado than Java zealot ;-)
This post has been deleted by its author
This post has been deleted by its author
I hear what you're saying but you can make it as readable as you like, eg.
"Smalltalk"
accountBalance := (AccountBalance format: 'zzz,zzz,zzz.zzdb'); showBlankIfZero; beTwosComplement
//Java
AccountBalance accountBalance = new AccountBalance("zzz,zzz,zzz.zzdb").blankIfZero(true).twosComplement(true).
This is the thing about OO languages, you aren't limited to only instantiating the objects the language designers gave you.
Okie-dokie ~
I don't think these examples are the same as the COBOL, as now we're into variable scope (global/local), ie. you're instantiating rather than "just" declaring (unless I'm reading that incorrectly). I'm not going to disagree that different languages can achieve the same results in different ways.
I stand by the nested title: PICs rule!
This is the thing about OO languages, you aren't limited to only instantiating the objects the language designers gave you.
That made me laugh, thanks for the pro tip :) And well worth one on me --->
o7
Here's another ancient source of design wisdom:
"Design of Man-Computer Dialogues" written James Martin in 1973
IME this is an undeservedly lost gem.
Its analyses of various ways a user can interact with a device and the way these map onto both the dialogue style and, equally important, the type of task the user needs to perform would make a huge usability improvement if the current crop of user interface designers had ever read it - or heard of it, for that matter.
My recently retired 60-something year old friend in Toronto's IT world is a multi-millionaire because of COBOL and FORTRAN! He has been hired numerous times over the last 40 years to revise, convert, update and extend all those IBM AS-400 and IBM mainframe financial processing systems. Starting out in accounting systems in Calgary, Canada during the 1980's after graduating from a highly-regarded local institute of technology where all that Oil'n'Gas Industry COBOL and FORTRAN programming they learned in college led to a VERY LUCRATIVE PROGRAMMING CAREER!
Once he was recruited by various Toronto, New York, Los Angeles, Chicago and London finance firms to upgrade all those COBOL programs because of the Year 2000 2-digit date bug, he was earning over half-a-million USD per year from 1993 to about 2001 on simple remote work contracts! And when IBM starting killing off the AS-400 minicomputer systems, he got hired for just as much money (and more!) for converting COBOL to JAVA code and IBM WEBsphere interfaces. Now, because of Open Source COBOL compilers, some older COBOL finance programs and FORTRAN trading programs are being moved from AS-400 and Mainframe code to Linux super-workstations and power-servers without conversion to JAVA but rather simple extension of old back-end COBOL/FORTRAN code mated to an HTML-5 web browser user interface. That lasted until this Spring 2022 when he finally had enough of remote working and decided to officially retire and travel! He has BOTH a lucrative US 401k and Canadian RRSP pension plan income which will see him, his wife and his now grown children very comfortably numb until the end of his days!
I should note that his COBOL and FORTRAN knowledge was so lucrative that he now OWNS free-and-clear multiple houses and apartments in Naples, Oslo, Toronto, Vancouver and Paris where he follows the temperate not-too-hot and not-too-cold weather as he desires for the entire year!
Both COBOL and FORTRAN can be VERY lucrative if you have experience in conversions to JAVA and HTML-5 interfaces or extending old back-end COBOL and FORTRAN code to run on modern Linux servers with web browser front-ends! Typical salaries are $150,000 USD to as much as $500,000+ USD depending on how desperate the bank or investment firm is! If you want a less stressful working life, many U.S. and European cities are also STILL converting old 1970's and 1980's-era COBOL administrative systems and FORTRAN-based engineering works code to newer JAVA and Windows/Linux systems so they offer usually around $65,000 USD to $125,000 USD per year with benefits and family-friendly working hours! The smaller cities and towns offer less money than the larger cities but your work hours and family life will be much better.
I would say there is STILL at least 20 years worth of COBOL and FORTRAN conversion work that still needs to be done due to the sheer number of cities, towns and financial systems that are STILL in the Year 2022 using older COBOL and FORTRAN code!
Sooooooo, for your new IT students and recent grads, learn how to code in COBOL, FORTRAN, JAVA and HTML-5 to get the lucrative many-times-remote-from-work programming that can make you a multimillionaire in less than 25 years! And in 25 years when all that COBOL/FORTRAN to JAVA/HTML-5 code conversion work is done, you can then use your new-found RUST and/or RUBY-on-RAILS skills so that all that older JAVA code can now be converted to a more memory-and-type-safe language which will take another 25 years to complete! What a lucrative long-term world-traveling and/or work-from-home IT career you will then have!
V
Me as well. I have about 150 students currently, in multiple sections, and recently taught a structured programming course for the first time in decades. Their comment on the course were "why didn't someone teach us this before? this is the easiest way to write understandable code I've ever seen".
I saw a few years ago in Ireland that (I think with IBM support) Technical Colleges were offering COBOL and zOS courses. It's definitely the smart move for anyone with ability and interest in computers. The number of working age COBOL programmers is dropping faster than the number of working COBOL programmes.
I somewhat doubt that all orgs with the stuff still around fully know the extent of how deep it runs...
In a prior life with a certain defunct bank, the meaty back end was hosted on lovely S/390 big iron with a mix mostly of COBOL and Fortran. And the list of people that knew their way around it was small, back in 2006.
Such knowledge has value, occassionally.
And the worst joke ever is:
Q: Why do female programmers hate COBOL ?
A: Period missing. Period assumed.
Background that you need to understand (yea I know, always bad when a joke needs an explanation), the most common warning message for all new COBOL programmers is:
COBCH1014 Period missing. Period assumed (You have omitted a period in a place where one is expected by the rules of COBOL syntax. Your COBOL system has assumed the period is present.)
And do not get me wrong I think COBOL is bloody fantastic, it has been about since 1959. I always think about the late "Grace Hopper" when I hear COBOL and smile. She was very influential in the creation of COBOL, was such a fundamental person in history of computers and she always made me smile when I heard her talk.
I remember going for an interview with MicroFocus for my 3rd year placement job at the tail end of the 80s. In the interview they asked my what language would I use to write the COBOL compiler in and I said stuff like C etc and why.
Their response?
Why wouldn't you use COBOL to write the compiler? That threw me, and I can't remember what I said in response but I didn't get the placement. Not sure if they still use COBOL to write their COBOL compiler (I assumed from the question that they did) but that seems like an exercise in masochism to me.
At times, I really start to resent the Reg "ancient tech" labeling of older technology that does exactly what it's supposed to do. COBOL is (IMHO) the first example of a domain-specific programming language, and for the problems it was designed for, there is no better choice. Admiral Hopper herself put it perfectly: "If people are going to describe their problems in English, the computer should be taught to understand English."
Don't knock it if you haven't used it. You can learn COBOL in less than a day, and it works. Is it good at everything? No. Does it allow business people to express problems in language they can understand and end up with workable code. Absolutely. Is it on every useful platform known to man? Yes. Not many things can say that.
From the sub-title--
"Stand up and be counted, ye ancient code wizards"
How does one know if the person responding to the imperative has interpreted it as
Stand up and be counted, ye ancient-code wizards
or, rather, to the completely different
Stand up and be counted, ye ancient code-wizards ?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
