20 Years in the Making, GnuCOBOL Is Ready for Industry

https://thenewstack.io/20-years-in-the-making-gnucobol-is-ready-for-industry/

by cglong • 2 years ago

180 114 2 years ago

thenewstack.io

ddgflorida• 2 years ago

Well that's exciting :)

proneb1rd• 2 years ago

Very exotic. Does it support multi threading? What kind of things can be done with it?

foobarian2• 2 years ago

I'm guessing it does money math in a certain way vetted by this field that would be very difficult to recertify on some replacement.

airstrike2• 2 years ago

For some value of "very difficult"

slt20213• 2 years ago

not the COBOL language, but the IBM mainframes have five nines of availability, duplication of every component, how swappable everything from power supplies to CPU and RAM.

Can get to more than five nines if used parallel sysplex, but the big iron is incredibly reliable. This is the reason why all banks, airlines, and other old-school businesses have been running mainframes and cannot ever migrate off of them.

this stuff was engineered like it was an airplane full of people

seanhunter• 2 years ago

But you need a modern enterprise-quality framework. Can it run Cobol on Cogs?

http://www.coboloncogs.org/INDEX.HTM

fredsmith219• 2 years ago

The vast majority of COBOL in production runs on IBM mainframes in conjunction with JCL (Job Control Language). If you are looking to offload COBOL from a mainframe to a cheaper platform JCL is a must. I love that this project exists but it’s only one half of a solution to migration off of a mainframe.

macintux2• 2 years ago

I’m unfamiliar with JCL, but from a quick search it sounds like most scripts don’t use much of the language. Still, I’d bet that most of the JCL functionality is used if you look at a decent-sized collection of scripts.

How much of the full JCL do you think would be necessary to reimplement in order to get, say, 30% of the existing scripts to work?

smackeyacky• 2 years ago

From memory of working with mainframe programmers back in the 1990s, it isn't just JCL you need. Cobol programs typically used databases and transaction monitors as well.

If you're lucky the database will be one of IBM's SQL databases. If you're unlucky it will be something like IMS.

guestbest• 2 years ago

Talking with mainframe guys for the last half decade, they seem to avoid JCL when they can and treat REXX like a super power.

cwbriscoe5• 2 years ago

Are these mainframe developers or system level guys. I wouldn't use REXX to run production batch processes. I would use REXX for TSO utilities and ISREDIT macros. JCL is pretty much a must for running batch processing. It is waaaaay more simpler and re-startable than trying to do the same thing with REXX.

__d• 2 years ago

When I last used COBOL (early 90's) we had a heap of JCL, for sure, but the real-time system used CICS for everything.

Is it still a thing? What's the FOSS solution for transaction monitoring?

NikolaNovak7• 2 years ago

>Get those punch cards back out!

I get that's (probably!) a joke, but it misrepresents COBOL as something completely stuck in the 70s. And, y'know, it isn't exactly the fanciest language in the world, but we still have several programmers on our project and they're spitting out new code every day of their life, no punchcards:).

(And it's not on a mainframe either - it's running primarily on AIX, with some of Windows and Linux).

airstrike2• 2 years ago

Let us join hands in a moment of silent prayer for those unfortunate souls

NikolaNovak7• 2 years ago

Eh. There are ways in which their lives are easier and more zen :)

ajxs3• 2 years ago

I've spent some time working in finance, so I've actually worked with COBOL developers personally in multiple different roles. In all those cases they were maintaining legacy applications that ran on IBM mainframes. Why would a company choose to use COBOL if they weren't restricted to what ran on IBM's mainframe infrastructure? Serious question, not an attack.

I get that many of these legacy applications are some of the most battle-tested things in existence, and do what they do very well. I've seen them in action personally. However I'm also under the impression that COBOL is just not that amazing compared with modern alternatives: It's not easy to write, or maintain, and (as far as I understand) the things that make it 'fast' have more to do with the platform than COBOL itself.

I'd love to know more about why someone would choose COBOL today, if anyone can fill me in.

santoshalper• 2 years ago

Nobody chooses COBOL as a language for creating new systems today. It is maintenance of existing systems, primarily but not exclusively, running on IBM mainframe and midrange servers.

chasil6• 2 years ago

We actually rely upon two different operating environments for COBOL that do not originate from IBM.

The first is OS2200. Our final major application on this platform was complete by 1970, and links COBOL into assembler that accesses the hierarchical DMS database. The first SMP port of UNIX was to this hardware:

https://en.m.wikipedia.org/wiki/OS_2200

The second is VMS, specifically the VAX variety. VMS bundled a COBOL compiler, which we used to write ACMS applications.

https://en.m.wikipedia.org/wiki/OpenVMS

We continue to produce new COBOL code for both.

p_l2• 2 years ago

A lot of COBOL in finance runs on x86 servers running MicroFocus Cobol on RHEL.

skissane5• 2 years ago

I'd love to know more about why someone would choose COBOL today, if anyone can fill me in.

I doubt anybody is choosing to start a new greenfield system in COBOL in 2024.

But, if you have an existing COBOL code base, and the business is asking for new features, you have two basic choices (1) write new modules for the existing system in COBOL (2) write the new modules in a more mainstream language (Java, C#, whatever) and have the existing COBOL modules integrate with those new modules (e.g. using REST)

Both options have their pros and cons. If you aren't already doing (2), then (in the short-term at least) (1) is the easier path.

cwbriscoe5• 2 years ago

COBOL is very easy to learn and write if you use it for what it was intended for. If you try to make a crud app or read from a web service, you are going to have a bad time. Trust me, I know. It can be done, but it is not pretty and was kind of shoe-horned in.

We have been trying to get rid of all of our COBOL and get off of the mainframe (many apps have been) for the past 20+ years. We are getting closer but priorities keep changing which keeps delaying that goal.

I love doing backend and db work so I would gladly switch to Go for my new projects. But, I would still need to use DB2, which (surprise surprise) is on the mainframe.

NikolaNovak7• 2 years ago

I cannot speak for all the COBOL implementations, but what I've seen is that a company will purchase and implement a new COTS ("Commercial Off The Shelf") back-office application such as ERP - Financials, HR, CRM, EPM, etc. Something that's boring to techies but critical bread and butter for a company.

That application may well have some COBOL in it. It's sold as new, but such big applications will have bits that were written 3 months ago and bits that were written 20 years ago.

Now the company has a shiny new application that has some COBOL.

ERPs are living applications. Legislation changes, markets change, company's needs change, so ERPs are both customized and updated and expanded. So you need some COBOL expertise depending how active you want to be about it.

(note: a typical techie, including myself a decade ago, will typically see insanity in this and think something like "Payroll???? How hard can THAT be??". Like being a parent or living through a civil war, nobody can truly explain this to another human being that hasn't been through it :-)

lupire2• 2 years ago

I understand that old programs are extremely stable, but I don't understand why they are relevant. The world changes so much, why are these programs still useful?

inkyoto2• 2 years ago

Why would a company choose to use COBOL if they weren't restricted to what ran on IBM's mainframe infrastructure?

COBOL has nothing to do with just IBM mainframes even though that is what it mostly runs on. The second big platform that runs COBOL programmes (heh, not apps!) on is OpenVMS (whatever hardware it runs on today) although the number of OpenVMS installations has seriously dwindled in the recent decade.

The reason why companies no longer choose COBOL is the mostly dead ecosystem and the lack of the fresh meat on the job market as a consequence of that.

If we imagine a parallel reality where COBOL is still thriving, many companies would almost absolutely choose COBOL for new projects because of its safe memory model at the very least – there is no memory corruption, no buffer overflows, no null pointer exceptions. If there are bugs in a COBOL programme, the bugs are related either to the logic or to the data handling.

With most programming languages of today, you have all of that too, plus compounding memory related issues even in considered «safe», garbage collected programming languages. The business generally does not care about the art of fine programming unless it will provide a substantial ROI (e.g. vastly reduced running and operational costs or it will yield a higher revenue), so the business would absolutely choose (or consider) COBOL in such a parallel reality.

simne6• 2 years ago

COBOL is just not that amazing compared with modern alternatives

To be honest, I'm new in field of mainframes, I'm just few weeks playing with Hercules.

But, after more than 20 years in industry, on micro- level (I near all my life spent with all sorts of x86 and with networking hardware, but also few years with Macs and with microcontrollers), I must say, only thing comparable to mainframes in reliability is Erlang.

And if I will take your words, just replace with regex /cobol/erlang/i, most will become truth, because, Erlang have much less LOC numbers, but looks like cost of massive reliability is same - not easy to write, or maintain (it is just too different from classic modern programming way), also Erlang is not very fast (experienced people said, it is close to Perl).

All these matter even considering Erlang syntax directly derived from Prolog, nearly best syntax in the modern world!

BTW if you want, I'm open to talk about how to make Erlang better for today, or even, talk possible ways to engage COBOL with Erlang on modern hardware.

_hcuq• 2 years ago

COBOL is my next career move. I'm tired of these modern languages.

pjmlp3• 2 years ago

With luck you will able to enjoy OOP if the compiler supports COBOL 2014, or even async/await with COBOL 2023. :)

iopq• 2 years ago

And some of those programmers are quite lively for being in their 70s!

NikolaNovak7• 2 years ago

That's just thing. I think there's this view/assumption that they're all in their 70s, and in some shops that may be the case; but this is an active system actively managed and enhanced/developed. These are normally aged developers :-)

(Heck, I did about 18 months of "some COBOL" along other stuff for a job right out of university. It's... fine? It's a language:)

Zenst2• 2 years ago

The punched card reference is most apt for COBOL, reason being the formatting and those limits dictated the column restrictions - hence COBOL historically had 80 columns max, and code sure does legacy when it's that mature.

riffraff• 2 years ago

It's ironic that the article later on mentions nonchalantly that there's an IDE built as a VS Code extension.

pjmlp3• 2 years ago

Indeed, COBOL 2023 has just been ratified.

rhaps0dy• 2 years ago

the past three years, it has received attention from 13 contributors with 460 commits.

That doesn’t sound like very many commits. Pretty mature!

Borborygymus• 2 years ago

In the late 90s I worked for a vendor of CRM software. A fair bit of billing and payment-handling code was written in COBOL. Wasn't mainframe - ran on a couple of flavours of proprietary Unix. The COBOL compiler vendor was Microfocus.

I didn't have any training in COBOL, but found it pretty easy to read and understand - at least for the fairly simple business logic in a billing system. I didn#t have to write anything - just do some debugging when it didn't output as expected. Wouldn't want to do anything too mathsy or heavy string processing with it, but it seemed a good fit for the application.

I did some more work for the same company later. A descendent of that software is still running today. At some point between 2000 and the late 20-teens they migrated to Linux, and I think at that point used some sort of COBOL-to-C transliteration software, and the Microfocus compiler was jettisoned. Not sure if the decision was because Microfocus was very expensive (I have heard that, but have no personal experience of it), or just didn't support Linux at that time.

That transliterated code is still running today, but a bit of a nightmare to maintain. If GNU Cobol has been mature enough whenever that migration happened, I suspect it would have been a much better approach than transliteration. Too late for that code base though.

chasil6• 2 years ago

The "mathsy" situation can be more difficult than most think.

GNU COBOL uses GNU MP by default for calculations, instead of IEEE-754, which came decades later.

Not understanding the math of COBOL has led to many failed porting attempts.

https://medium.com/the-technical-archaeologist/is-cobol-hold...

vesinisa• 2 years ago

I hate that it's spam-walled but that Medium article sure was a riveting read.

Basically the conclusion is that for mainframe systems that need to process lots of transactions fast the performance of COBOL is hard to beat. Languages like Java are not even very well suited for these type of calculations since BigDecimal is not part of the core programming idiom.

With the additional cost that migration would carry, it's actually less risky and more cost effective to keep maintaining the COBOL system, even if it means paying in-house to train programmers in this ancient technology.

guenthert• 2 years ago

"And when you understand how Java does math and how COBOL does the same math, you begin to understand why it’s so difficult for many industries to move away from their legacy."

Would it have killed her to tell, how COBOL does the math? I would think that for financial transactions fixed precision arithmetic is used, so IEEE-754 compatibility is irrelevant.

mseepgood• 2 years ago

What took so long?

musicale2• 2 years ago

COBOL's boilerplate doesn't seem that much worse than what Java programmers lived with for decades.

7thaccount2• 2 years ago

The big difference is I think Cobol typically (but not always) requires knowledge of the mainframe as well, while Java more or less requires some basic OS knowledge, JVM, and all the boilerplate.

Edit: mainframes seem neat, but I wouldn't want to code in either personally.

ngcc_hk• 2 years ago

They are both verbose. But cobol is more data definition oriented.

xunil2ycom• 2 years ago

I award them no points, and may God have mercy on their souls.

asp_hornet2• 2 years ago

This exists because most modern rewrites of COBOL systems have been rewritten several times over despite the rewrites never finishing all the functionality of the original.

Modern day software engineers need to eat a huge slice of humble pie.

michaelsbradley• 2 years ago

Don’t miss the GnuCOBOL FAQ and How To, perhaps one of the largest such documents ever compiled:

https://gnucobol.sourceforge.io/faq/index.html

(may cause mobile browsers to crash while loading)

Zenst2• 2 years ago

"Compliance-wise, it passed 97% of COBOL 85 conformance tests, a success rate not yet achieved by proprietary vendors, Sobisch boasted."

Thinking about that if you step back is amazing, to think a standard written in 1985 (I was doing COBOL back then into the 90s) has yet, even today not had any of the big names/players meet full compliance nearly 40 years later.

I'd love to read more about that aspect

vram223• 2 years ago

I'd love to read more about that aspect

See the

  DATA DIVISION. 

  FILE SECTION.

chungy• 2 years ago

From an SQL background, this doesn't really surprise me at all. PostgreSQL is the closest anyone's ever got to being fully ANSI SQL compliant, with most of the proprietary vendors having rather paltry compliance numbers.

pjmlp3• 2 years ago

Same applies to SQL, FORTRAN, JSEngines, POSIX, even C and C++ compilers, if you bother to go through all the little letters legalese on the standards and cross check with their latest implementations, outside the big three it is even worse.

It appears everyone only strives with good enough, fine tunes with bug reports for lesser known features and that is about it.

zulban• 2 years ago

That hello world program is brutal. Truly, the language is the first of its kind.

Hopefully this helps fleets of developers bring their legacy code (more legacy than most of us can imagine) into a modern stack, and start applying modern SWE principles to it.

magpi3• 2 years ago

It's logical and it makes sense. I would argue, at first glance, that C's hello world (#include <stdio.h>, int argc, char ** argv, etc) would be more confusing to a total newbie. Java's even more so.

globalnode• 2 years ago

one of my subjects at uni in the 90's (IT degree) required me to learn cobol. god i hated that class. thankfully i dont remember much of it. it was actually before we learn't c/c++, also VB was a big thing then too.

nxobject2• 2 years ago

There’s no support yet for objects or messages in GnuCOBOL. Objects was “a nice feature from COBOL 22, which isn’t used that much,” Sobisch said. Messaging just got reimplemented recently, and is still a new feature for the COBOL crowd to grapple with, Sobisch said. So, no support in GnuCOBOL yet.

COBOL 2022. My god.

mise_en_place• 2 years ago

It’s interesting but will anyone actually use it? z/OS for example doesn’t have a hierarchical file system. The version of COBOL they bundle supports data sets I’d imagine. Legacy folks will be hesitant to switch to it as well. When I worked at a bank they couldn’t even use the latest Java, due to compliance and regulatory reasons.

20 Years in the Making, GnuCOBOL Is Ready for Industry

Related Stories