An open-source COBOL contender emerges The newly announced gcobol compiler is a fresh front end for GCC, and builds native binary executables. There are already other FOSS and freeware compilers for COBOL out there, but few are fully open source. Notably, there's GnuCOBOL, which evolved out of OpenCOBOL. The OpenCOBOL FAQ is worth a read, and notes that: "OpenCOBOL …
In the 1890s, newspapers didn't have a drastic ink-rub problem, thanks primarily to the letterpress that they were printed on and the solvents and inks in use. It wasn't until the advent of the Vanguard Web Press in the mid 1950s that newspaper rub-off became a major issue.
By the 1990s, however, rub-off had been solved. In fact, the San Francisco Chronicle even advertised it's new flexographic presses with no-rub ink as a selling point in the late '80s or early '90s.
There's a couple brain cells that you'll never get back ... We now return you to the usual bickering.
You don't need object oriented FORTRAN, or ever will .... as we knew in 1982
" Now they're dying off, and increasingly desperate COBOL users were previously appealing for volunteers to help."
It's not a problem yet. When they stop relying on volunteers and offer to pay for hours, that's when you know there's a serious business issue.
*Icon: waiting to code until the wallet is in reach
To read the 2014 COBOL standard, iso.org invites me to cough up 198 Swiss Francs for the privilege.
There are too many closed standards like this. Not just software standards either - mechanical and electrical standards can only be read by those with deep pockets as well. The problem is the same with academic papers - you can identify papers from 60 years ago which are relevant to your own personal research only to find them locked behind the academic distribution mafia's paywalls. The way technical and scientific information and knowledge is published today is utterly broken.
Far from "furthering knowledge", the distribution and publishing cartels actually slow down innovation and education. The only thing furthered is the cartel member's bank balances. The cost of access to standards, journals or research papers restricts their availability to those with business licenses or very well off citizens (if allowed).
Access to knowledge should not be decided by how much money you have.
But only as "illegal" services under constant attack by Elsevier and similar cartel members, leading to those sites being blocked in many EU countries and to significant legal risk for those who run those services if they travel via the wrong country.
A lot of the documents held hostage behind the cartel paywalls were actually created by public organisations with public money. It shouldn't even be legal to ransom these documents for the distribution cartel's financial gain.
The phrase "misappropriation of public property" comes to mind.
Yeah, for many people, the draft standard is fine. You really only need to pay when you need to say you've consulted the actual, official thing.
Still, it's a problem, and I wish more commercial software-development organizations just budgeted to subscribe to the standards relevant to their work, for all their developers. I've settled too many language-lawyer questions just because I paid (out of my own pocket) for the standards.
For C90, back in the day, many people bought Schildt's The Annotated ANSI C Standard, which contained the complete text of C89 (the ANSI version, adopted wholesale by ISO the following year). The book was cheaper than the standard document from ANSI, but contained all of its text, plus Schildt's commentary.
The standard review on comp.lang.c was that the cost difference was the value of Schildt's annotations. Still, you were free to ignore those.
I could almost stomach paying for useful standards, but even worse than hiding standards behind a paywall is when they:
* Have one standard reference three more, each of which references yet more standards.
* Update a standard every couple of years with insignificant changes that still require obtaining the latest version.
* have two or more standards from SAE, ISO, DIN, etc. that are pretty much the same, but aren't identical so you need multiple copies.
At work I have access to an internal tool that gives me access to pretty much any standard I can dream of (already bought and paid for). Even relieved of the financial concerns the hassle of the above bother me.
If its a standard I have to pay for ... it's not my standard. Never will be.
Public and accessible? Now we're talking.
One of the key things, often overlooked, is that part of the FOSS, is that it also supports FOSS, where the second 'S' is standards. It's the standards that foster information interchange, and add value. You close that standard, you just restricted communication and value.
Get the GNU Cobol Programmers guide - not read the standard but this seems to cover anything you need to know. I do agree with you on mafia pay-walls but there are often people who work round them and growing armies of open source offerings which offer a life time of free learning and sometimes a visit to a library can locate some of the stuff via their library share stuff - best in a large town or city!
LONG LIVE COBOL!
Seriously, there are more functional lines of COBOL and Fortran working in big business today than the average kid who never used a dial telephone could possibly imagine. I do not know of a single COBOL or Fortran programmer who is currently out of work. I can't say the same for Java(script), VisBas, C++, C#, and what-have-you. Not a month goes by when I don't get email from a former student, thanking me for suggesting COBOL or Fortran as another programming language to learn ... The two are pretty much ubiquitous in big business.
First posted here: https://forums.theregister.com/forum/all/2009/01/07/64-bit-cobol-for-aix/#c_398757
I was a COBOL programmer and I'm out of work. I haven't been actively (read desperately) searching but I've been getting some responses from a 'send me updates' from Indeed. The ones I'm looking at right now says 'mainframe experience 10 years required, CICS, MVS JCL, TSO, QMF required'.
I was unfortunate enough to spend 20 years writing COBOL on the wrong platforms. First for a Texas Instruments mini setup using their version of Ryan McFarland, then MicroFocus's version that ran on client / server pcs. The latter used true blue IBM DB2 precompilers, but still no 'mainframe experience'.
I'm 65+ and have no desire to move, so ya, I guess I'm just too lazy to get out there and pound the pavement to get the big bucks but please don't say if you can spell COBOL without spelling Cobalt you can get a job. It just ain't true.
Seconded. I'm another who spent two decades with COBOL on the wrong systems. In my case BOS/COBOL and a database driven variant carried Speedbase running on BOS, a now-obscure cross platform operating system geared up to provide multi-user business applications on commodity hardware. (24 serial terminals on a 286 was one system I supported. It worked well.) I never even came across the Big Iron ecosystems.
(if anybody has any work to offer.... )
My buddy in Toronto just recently retired and he was earning over $500,000 USD per year doing COBOL work for major banks and trading houses in Chicago, New York and London while living mostly in Toronto.
He did everything from AS/400 Minis to IBM-Z-series COBOL to DEC VAX COBOL mostly doing COBOL to JAVA and C++ conversions.
He finally retired after doing the last 20 years NOTHING BUT COBOL conversions. With investments he now has quite a bit over $10 MILLION USD cash in the bank and just finally retired to his British Virgin Islands mountain luxury house to live a life of forever-more fishing and travel!
It can be VERY PROFITABLE if you know BOTH MATH (Linear Algebra, Advanced Calculus) AND COBOL, JAVA and C++ -- New York firms are offering contracts from $500,000 per year up to $1.5 million per year if you can finish the conversion jobs as lead programmer in the time required!
Mostly just automated FAST trading programs and trend graphing programs originally running on DEC VAXes, IBM AS/400's and IBM Mainframes and Sun Workstations/Servers of 1970's/1980's era code!
Soooo, COBOL is NOT dead! Many cities STILL use 1960's era COBOL and FORTRAN to run their older infrastructure AND to do employee payroll and job administration! Even that low-level conversion work is $150,000 per year on contract PLUS bonuses! You have AT LEAST 10 to 15 YEARS of solid money-making COBOL conversion work just in the Northeast USA alone!
If you want a warmer climate, Singapore and Southern Japan ALSO have probably 20 more years of COBOL conversion work for their 1980's era government computer infrastructure still left at around $200,000 USD per year salary. You'll be a really SMALL TEAM of just 1 to 5 programmers to do decades worth of work BUT it will be profitable AND you get yearly bonuses! You get an air conditioned office with a nice view and some nice desktops! It's a pleasant job if you can get it!
Agreed. I can wrap my head anround any programming skillset, I spent yesterday adding 8051 coding to my skillset. Coding is coding is coding is coding. Where are the employers demanding to employ me? They refuse to acknowledge how much of coding is interchangable swappable skills, they admantly insist on only considering people who are actually already working on the actual project they are recruiting for.
I thought I could learn any language out there also. I paid my rent writing COBOL against DB2 data in the 80-90's, took classes in C and Java, wrote a JSP e-commerce website somewhere around 2006, wrote a simple Android app around the same time and then, around 2019, decided to look down the dark tunnel of front-end programming. HTML5, CSS3, javascript with node.js, angular, react, ajax, bootstrap.js, jquery, json and PHP. I spent about a year trying to learn this shite on my own. I don't know at what point I decided this just wasn't worth it, but it just seemed to be too much 'cute' code - i.e., how much you can do in one sentence and not be obvious in your intent. I also didn't like the way javascript isn't type-safe. The difference between procedural and functional programming paradigms? Maybe. Or I just might be old.
[Article author here]
You will note that I did *not* say "paid a ton of money", or in more modern SI-compliant terms, "a tonne of money."
I merely said they'd be (more or less) guaranteed a job. I didn't say anything about whether it'd be a *well-paid* job.
A chap I knew with slightly dated programming skills spent a long time looking for work after the Credit Crunch. Nothing going: nothing in C* or Delphi or anything he'd done in the 20th century.
Then, he told me, he had a brainwave. He read about old codgers getting Y2K remediation work, and rewrote his CV to focus on the oldest language he knew: Fortran.
Subsequently he'd been employed at full contractor rates for several years. The first role he landed accepted that he'd have to get back in practice and modernise his knowledge a bit; they were just happy to have someone who they didn't have to train from scratch.
After that, it was renewal after renewal. Occasionally he would turn down offers if they weren't well-enough remunerated, but use the offer to get a pay bump.
When I was hunting for sysadmin work around the early noughties, I got far more interest for knowing OpenVMS than I did for more modern systems.
Ageism is rampant in the IT world, but if you are canny, it can be possible to turn this to your advantage by maximising obsolete skills that nobody without grey hair knows anything about.
True. The reason COBOL continues to exist is largely (though not exclusively) to continue to glue together what used to be called "teleprocessing" applications.
It's quite remarkable that, despite originating in the 1960s, being impenetrably arcane and multiple attempts by IBM to kill it off, CICS is still so widely deployed - especially at a time when so many systems are being rewritten for no better reason than to be "modern".
Perhaps it is because it's impenetrable and arcane and no-one really knows what their legacy code actually does. In which case, having a compiler is likely to be the least of your worries - though congratulations to those who put in the effort.
Oh, be reasonable. Are you telling me that EXEC CICS BIF DEEDIT FIELD(ws-foo) LENGTH(7) RESP(ws-bar) RESP2(ws-baz) END-EXEC1 is not intuitively obvious? Why, it's clear as day!2
But that's a legacy code base for you. Vast landscapes of undocumented, largely comment-free source — when source is available at all. Sometimes people just have faded listings on paper. Sometimes no source code at all. No one knows exactly what operations and calculations those applications perform. Replacing them would be a major feat in software archeology.
And why take the risk, when you can put a modern3 front end on the thing, by screen-scraping, or using an environmental mechanism like EXCI, or tacking a web API over the business logic. You get a new "user experience", management is satisfied, none of the incomprehensible tangled mess needs to be unpicked.
1Not to be confused with BIF DIGEST, which does something entirely unrelated.
2It's snowing quite heavily here.
3For arbitrary definitions of "modern".
We have plenty of COBOL customers who are not using CICS or IMS or z batch-mode environments.
It does seem to be common to tie COBOL jobs to particular environments: "we want someone who can write COBOL for Siemens BS2000", as if people capable of working on that machine are born that way and couldn't possibly have learned it.
That said, the COBOL standards leave ample room for major differences among implementations, and pretty much all of them have extensions. So you can't just move COBOL expertise from one implementation to another. And it's also true that real-world COBOL applications will have to deal extensively with their environments. But these are things which can be learned.
"and these languages have not been put out to pasture.".
Hasn't happened to you either one has to assume.
My first reaction was that it must be much older but instead it was quite young like I when we met the first time.
I newer had any greater conflicts with that language or any other as I accepted what the company I worked for used, how else.
Unlike horses or people software doesn't actually age. If it did a satisfactory job in 1960 then its going to continue to do the same job in 2060. COBOL programs in particular are a mechanization of a business process, a process that may well predate computers as we know them today, a process that might date back decades or even hundreds of years. Its possible to add to the process, improve the interfaces, extract additional information from the workflow or whatever but until the underlying process changes there's nothing to be gained from meddling with the implementation.
That's the danger of rewriting the code in a modern language. The temptation will be to meddle with the process. This carries significant risk.
One thing I discovered about programming in general is how much of it was inspired by business and other practical work, If you actually learn what you are coding about and why its not long before you can recognise good and bad business decisions made by those without the ability to sting together the tools they should have easily to hand. That's when the fun starts!
>COBOL programs in particular are a mechanization of a business process
Too many decades back I did get involved with the migration of COBOL to C (ie. when C was the fashionable language of the moment), the laugh was that the C code to do the same functionality was a mess as it tried to handle all the stuff COBOL just did. So the solution was to create libraries etc. and before you knew it, the C started looking a lot like COBOL...
The problem COBOL and Fortran have, isn't that they are old - C is 50 this year and other more fashionable languages are middle-aged, but that they somehow gained the reputation and thus are perceived and mocked as being long in the tooth and not fit for use by "real programmers".
> business process, ... that might date back decades
The thing about business processes is that they change frequently. Businesses are about competing with others and trying to increase their revenue and profit. They will change the way they set prices, discounts, they will change the product they sell, the way that they sell them. If they don't do that then their competitors will and will take business from them. The computer systems are required to be amended to implement these changes.
> rewriting the code in a modern language
Back in the 80s there was a Datamation survey that reported that 80% 9or so) of COBOL programming was reported as being 'maintenance' whereas 90% of C programming was new applications. Some seemed to conclude that if COBOL programs were converted to C then the 'maintenance overhead' would disappear and the programmers would create new applications.
The whole survey was seriously flawed. The COBOL and C sites were doing completely different types of applications. The COBOL 'maintenance' was, in fact, updating the business applications to handle changes in the business processes as the businesses re-invented themselves to compete better.
I do understand nostalgia when it comes to video games. I also understand there are many lines of Cobol lying around everywhere.
Heck, I'm even working with an excel sheet packed with thousands of lines of VBA-COBOL, those days !
But I really don't understand why one would develop a compiler for such an inferior language. Just emulate your AS400 FFS ! Like running Lemmings on an emulated Amiga !
"But I really don't understand why one would develop a compiler for such an inferior language. Just emulate your AS400"
Why lose performance emulating something instead of compiling to native code? The COBOL code carries out the business that pays the bills for the company. There's nothing inferior about that.
Inferior language? By what measure?
Cobol is a big language, that's for sure. It codifies things most languages leave to libraries: file I/O, file structure, file availability, text encoding, sorting (files and in memory), and merging. For every failed operation, whether I/O or buffer exhaustion or arithmetic overflow, the language includes error-handling. Errors can be handled statement by statement, or globally, or by function, or sets of functions.
I have found that most Cobol critiques, like most programming language critiques, are skin-deep. Lisp has too many parentheses; Python uses whitespace; Perl is write-only; APL is impenetrable. These are not useful measures of the utility of the language.
It's also easy to mock Cobol for some of its antique conventions. But it's good at what it does. I defy you to rewrite any significant Cobol program in any other language of your choosing, in fewer lines or words.
If you're old enough to be brought up on dry but fact filled manuals
https://gnucobol.sourceforge.io/guides/GnuCOBOL%202.2%20NOV2017%20Programmers%20Guide%20(US%20Letter).pdf
and you can have fun with some of the older free manuals on PDFs by setting up the machine simulators for the machines and DBs they ran on and accessed!
Writing a COBOL front-end for GCC is a nice project. And there's some green-field COBOL development, and some number of existing COBOL applications which don't stray too far from the ISO standard; thus the success of GnuCOBOL and COBOL-IT.
But the standard allows tremendous latitude, and implementations have dramatically different behavior. Nested PERFORMs behave differently on different platforms, for example, and the differences control where the program ends up at the end of a PERFORM, so that matters a bit. MF Visual COBOL currently has 17 dialects to pick from at compile time, more than 30 options for tweaking the dialect, and 50 or so other ways to modify what sort of COBOL the compiler actually implements. (And that doesn't include the OO or managed dialects, conditional compilation, or other runtime-behavior options.)
And as others have pointed out, most real-world COBOL applications will depend heavily on the environment, whether that's one of the IBM mainframe ones such as CICS or something else. Yes, there are COBOL programs which just use POSIX / SUS or Windows APIs; but they're in the minority.
Michael, if you have an actual challenge for us, with money on the table, please get in touch.
Our business model does not include trying to emulate every Cobol ever written. Rather, we know there are businesses that could save millions of dollars per *month* running Cobol applications on LInux. Most of them are unwilling to jump out of the frying pan and into the fire: from one proprietary vendor to another. It's also difficult to assemble on Linux the suite of services (RACF, IMS, JCL, etc.) that production Cobol applications rely on.
Because Cobol environments are highly particularized, there is no such thing as "drop-in replacement". What a working Cobol compiler offers is the opportunity to move the application without re-writing it in, say, Java. Success will nevertheless require adjustments to the code and possibly, as you say, to the compiler. We know how to do that.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
