COBOL: A 1959 Idea and 2022 Technology
dzone.com
dzone.com
> Easy to Understand, Anywhere You Like
Cobol is trivial to learn, read and write. The difficulty comes from the lack of abstractions and sheer volume of legacy code. Lets be clear, there is virtually zero green field development using newer Cobol standards, and the vast majority of code out there are the massive Cobol 85 applications that have evolved over decades to encompass and encode processes for entire industries.
We've consistently seen reports of a shortage of Cobol developers the past few years. Cobol applications are cost centers and the companies that have them have been seeking to minimize their costs for a long, long time. Over the past 20 years there have been waves of offshoring that have gutted the ranks of the system experts. There are tens of thousands of laid of Cobol developers in the US alone. The jobs went offshore. The only shortage is in Cobol developers with domain expertise, precisely the ones that were fired many years ago, who will work for low wages on offer.
It does however, perhaps conveniently, ignore the complexity of the COBOL runtime environments like VRX, CICS etc from mainframe days. One think I like about GNU COBOL is it transpires to C and then compiles that. So you can run in most of the modern nix environments.
My other involvement was teaching SQL to COBOL students.
FORTRAN shares with COBOL the mantle of the first compiler languages. As pioneers, they were stunted.
I remain a fan of PL/I for applications. It learned from the limitations of the early languages, but too many managements wanted to keep things stupid simple.
Mind you, PL/I would happily allow you to program in inefficient ways with serious performance costs.
You require knowledge of the code the compiler produces and which parts of the subroutine library are best avoided before you can promulgate standards for production applications.
FORTRAN shares with COBO
PL/M last I looked was not allowed outside IBM development labs, but I see a bunch of stuff coded in PL/M. My impression is that it's basically a bunch of macros wrapped around Assembler instructions in a common quest to eliminate branch instructions.
But remember that every IF and loop is implemented with branches under the covers.
The real problem with learning COBOL is the surrounding infrastructure, such as CICS. Now, that is a bugger.
The language capability and their tech level was extremely low. I got superpowers like grepping the full code base for a thing to refactor, or writing an sql select statement that could query a whole table at once, instead of just 1 record. Otoh, I ran into trouble when trying to integrate an url longer than 1 line of 80 chars. Non ISO8859-characters are still impossible over there.
Their superpower was explaining what the business actually did, what edge cases were forgotten,...
The unfortunate truth was I was easily replacable with any dev from the last 20 years, if only someone wanted to actually talk to them instead of stonewalling them for their incomprehensible elder rituals. And I got paid a lot better, too.
[1] https://sourceforge.net/p/gnucobol/discussion/cobol/thread/7...
It is my mission to remind people who might buy into that myth that COBOL is a clunky, boring language and that it's also not true that's where the easy money is.
It basically took reports formatted for the multi-carbon “greenbar” paper that normally went to the big dot matrix printers and sent them instead to print on the then-new HP2680a desk size laser printer.
They made me emulate the look of greenbar paper on the white fanfold laser prints because that was what people were used to.
Good times…