So, now we all know the Blondie song written in Object Cobol:
This.picture my telephone number
Get a pocket computer
What I'm telling you is one and one
Stop (FFS stop)
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.
" 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.
[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
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
Though the Wordle fad appears to be fading, engineers continue to find new and exciting places to port the game. Today we present a version using Pascal on Multics.
For those either not of a certain age, or unaware of historical operating systems, Multics (Multiplexed Information and Computing Service) dates back more than half a century (development of the OS began in the 1960s) and is a time-sharing operating system.
It is an undeniably neat system, with a modular architecture supporting both scalability and high availability. Resources could be added while the service was running, and security was front and center with innovations such as file level access controls.
On Monday, software developer Drew DeVault announced a systems programming language called Hare, describing it as "simple, stable, and robust." We've all heard that before – but there may be something in this.
More than 400 programming languages have existed at one time or another. Hare aims to serve as an alternative to C – arguably the most significant programming language of the past 50 years.
DeVault and about 30 project contributors have been working on Hare for about two and a half years. They've now let their rabbit loose so developers can run with it.
Aria Beingessner, a member of the teams that implemented both Rust and Swift, has an interesting take on some of those (and other) language's problems – that C isn't a programming language anymore.
There are many problems with the C language. To pick just a few: it can be difficult to parse; there are competing and subtly incompatible variants; and then there are the complex ways C defines and handles integers and other variables.
Believe it or not, not everything is based on C. There are current, shipping, commercial OSes written before C was invented, and now others in both newer and older languages that don't involve C at any level or layer.
Computer hardware is technology yet very few people can design their own processor, or build a graphics card. But software is a form of culture. Open source is created by volunteers, even if they end up getting paid jobs doing it. Even rejecting open source is a choice: paying for Windows or macOS instead reflects a preference.
This is especially visible when it comes to text editors, and even more so about programming languages. People get passionate about this stuff. So statements such as "C isn't a programming language any more" can be upsetting. Most people live and work in the cultures that are Unix and Windows and if they are all you've ever known, or know best, then it's easy to think they are the whole world.
Oracle's Java 18 development environment has hit the streets, with Big Red promising nine enhancements including the ability to add sample source code to API documentation.
Other new features include Simple Web Server (JEP 408) for prototyping and testing, two incubating modules, as well as the preview of Pattern Matching for switch (JEP 420).
Java 18 JDK (Java Development Kit) is set to be a short-term release, supported for six months until the next one appears every March and September. The most recent long-term support release is JDK 17, which came out last September, the previous being JDK 11 from 2018.
The folks at Deep Instinct say they have studied a Go-written variant of the malware used by the Arid Viper cyber-crime ring.
Deep Instinct, founded in 2015, says it uses deep learning to detect and block malware. While training a deep-learning model that's focused on identifying software nasties written in Go, the researchers uncovered an executable file built using the programming language, submitted it to the VirusTotal website, and found only six security vendors had the binary flagged as malicious.
Further investigation uncovered two similar Go-written binaries. From these programs, we're told, it became clear the team were looking at a variant of Micropsia. This malware was identified in 2017 and is used exclusively by Arid Viper, an advanced persistent threat (APT) group believed to be based in Gaza and known as APT-C-23. Deep Instinct named the Go-written malware Arid Gopher.
Google is planning to tighten the security around its open source Go programming language by requiring two Google employees to be involved in code changes, where previously only one approver needed to be company-affiliated.
"For compliance and supply chain security reasons, Google recently revisited the code review requirements we use in all settings, both internal development and open source," explained Russ Cox, distinguished engineer at Google, in a note to the golang mailing list on Monday.
"We are now required to have two Google employees review each change before it is shipped to users, which for most of our tools means submitted in [code review system] Gerrit."
Opinion Here's a recipe for happiness. Don't get overexcited by the latest "C is not a language" kerfuffle.
Proper coders have known since its inception that C is as much a glorified library of assembler macros as anything else. Don't sweat it. That business with operating systems being infected by their old C genes, crippling all the new cool Rusts and Swifts? So what? If your code is limited by its OS interactions, you should probably go write a kernel.
There is one place, and one place only, where you should invest your emotional and intellectual energies. Compilers. They saved the world once, and they're about to do it again.
Brandon Nozaki Miller, aka RIAEvangelist on GitHub, created node-ipc, which is fetched about a million times a week from the NPM registry, and is described as an "inter-process communication module for Node, supporting Unix sockets, TCP, TLS, and UDP."
It appears Miller intentionally changed his code to overwrite the host system's data, then changed the code to display a message calling for world peace, as a protest against Russia's invasion of Ukraine. GitHub on Wednesday declared this a critical vulnerability tracked as CVE-2022-23812.
It's that time of year again, when all good little developers count down to the festive season with the Advent of Code.
It's a gloriously simple concept. Much like the Advent Calendar, each day in December, up to and including the 25th, contains a treat.
However, rather than pictures or vaguely stale chocolates, each Advent of Code day presents a coding challenge that needs solving.
Biting the hand that feeds IT © 1998–2022