COBOL for Linux on x86 1.1 is the latest addition to the IBM COBOL compiler family, which includes Enterprise COBOL for z/OS and COBOL for AIX. COBOL for Linux on x86 is a productive and powerful development environment for building and modernizing COBOL applications. It includes an optimizing COBOL compiler and a COBOL runtime library. COBOL for Linux on x86 is based on the same advanced optimization technology as Enterprise COBOL for z/OS. It offers both performance and programming capabilities for developing business critical COBOL applications for Linux on x86 systems. COBOL for Linux on x86 is designed to support clients on their journey to the cloud. It enables clients to strategically deploy business-critical applications written in COBOL to a hybrid cloud environment or best-fit platforms, which includes IBM Z (z/OS), IBM Power Systems (AIX), and x86 (Linux) platforms.
As I understand it, there’s still a lot of COBOL code all over the industry, so it makes sense for IBM to make its COBOL technologies available to more people.
I don’t think this is a new thing. COBOL compilers for Linux exists for a long time. There’s the Fujitsu offering aka NetCOBOL which has Linux support for years. Obviously Micro Focus have their compilers available for Linux. This whole “IBM brings COBOL to linux” is as much marketing BS as claiming a new Logitech update is bringing “Mouse support to windows”.
There are two main issues with all these solutions, and the IBM one, if I read the marketing copy correctly. First, it’s not open-source/free software. Meaning you buy a license to a black box that you don’t control and can’t modify. The second issue is that all those vendors ship their COBOL implementations with proprietary expansions. These are vendor-specific non-standard features that, once used, mean the company is now locked-in to IBM/Fujitsu/MF line of products, and any attempt to move to another vendor will require rewriting and basically porting large parts of existing legacy code. This is mostly why IBM is still such a powerhouse, as companies that bought into them 40 years ago are still stuck there.
There’s an alternative, but I don’t know how good it is. A project originally called Open COBOL and now GNU COBOL is free software and implements most of the 85/2002/2014 COBOL standards. There are two main issues with it. First, it compiles the COBOL code to C and then compiles it to a C binary. This isn’t optimal for many reasons. The second issue is that “mostly” way of implementing said standards. This means that even if a company made sure to not use any proprietary features and only stick to the standards, they might not be able to run on GNU COBOL (but is 100% guarantee to run on all commercial offerings).
To be honest, the COBOL situation is so integrated into legacy machines, that most companies who use it don’t bother trying to port it to another architecture, let alone another OS. They are still using mainframes running the ancient compilers.
GNU COBOL not being IBM COBOL is the problem. Like most GNU things, it’s not quite the same thing, and I gave up because it’s not 100% the same thing when I looked into this a few years ago.
Yes, this is not a new thing.
I started using AcuCOBOL (now Microfocus) on Linux systems since later 90s, IIRC. Today I still use AcuCOBOL Runtime licenses on Linux 64bit for running (and also maintaining) COBOL applications on CentOS 7.
So apart from supporting legacy systems, is COBOL better at doing anthing than other languages?
COBOL has its limits as probably any language. The (modern) user interfaces has changed a lot since 80s and 90s. I mean, COBOL was created for text mode interfaces (display and printers) and that’s where it has part of its power. It’s a very good language for accounting and billing applications. Of course, and since 2003, AcuCOBOL extended the language to include new sections, clauses and statements to be able to build decent COBOL graphical applications for Windows.
In all, is an friendly language, is fun to program and it has a very good abstraction level regarding how the data is saved on files (data bases).
But don’t get me wrong, I also love C and Perl which I use daily to develop personal and professional projects.
Running faster on each successive hardware generation and extreme backwards compatibility, mainly.
COBOL can’t be separated from the mainframe hardware it runs on. Mainframes are different beasts. By comparison, x86 servers are built on the YOLO principle.
Running production COBOL on x86 is kind of dumb, but COBOL does need to run on x86 in order to onboard new programmers. Without COBOL running on x86, real IBM COBOL running on x86, there is a chicken egg problem because mainframes aren’t something anyone can pick up.
I don’t know how to say it in the right way. COBOL has a reputation for being a pain, and it is a most certainly a pain. However, deep sigh and a pause here, the way its designed you have to be a complete blunderhead to do accounting wrong. Its designed to make that not easy, but really difficult to screw up. Yes, you could do it with any other language, but the things COBOL is good at doing are difficult to do wrong with COBOL. Think of it as an accounting DSL, basically.
Contrary to the doom and gloom posters above, this is pretty awesome. 🙂 Not having to rely on GNU COBOL is nice.