Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

20 Years in the Making, GnuCOBOL Is Ready for Industry

thenewstack.io

Post reply on HN
Print view View original

81–90 of 118 posts

Re: 20 Years in the Making, GnuCOBOL Is Ready for Industry

#81

Post by ajxs »

miki123211 wrote: post #47
lupire wrote: post #36

Earlier quoted context omitted.

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?

The world changes little-by-little, not all at once. Let's say your application (100k LoC of Cobol) handles payroll. Your government introduces some new rules about how paternity leave should be handled. You have two options, rewrite the 100K lines into Java and add the new rule, or just add the new rule in the Cobol app. The latter is cheaper, at least in the long term, so that's what you do. Now you have 101k lines…

I've worked at organisations which have mainframe applications that have been running for almost 50 years. One of the funnier reasons I've heard about why these '100k lines of COBOL' programs never get rewritten is that no one really knows the full extent of what they do, and even if they do know the full extent of what they do, no one really knows the full extent of why. The business requirements that these programs cover are long since lost, but the program still remains. Even if this isn't a 100% true anecdote, it's an amusing one.

Re: 20 Years in the Making, GnuCOBOL Is Ready for Industry

#82

Post by ajxs »

skissane wrote: post #23
ajxs wrote: post #13

Earlier quoted context omitted.

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…

> 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#, whateve…

You're right. I think I misread the original post, and assumed that since they were talking about running COBOL on more modern systems that they were using it to solve new business problems, hence my confusion.

Re: 20 Years in the Making, GnuCOBOL Is Ready for Industry

#83

Post by guenthert »

chasil wrote: post #45
Borborygymus wrote: post #21

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…

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...

"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.

Re: 20 Years in the Making, GnuCOBOL Is Ready for Industry

#85

Post by p_l »

vram22 wrote: post #62
p_l wrote: post #20

Earlier quoted context omitted.

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

And on Xenix earlier, and on SVR4 and SVR3.

Suspected System V, and there was definitely a lot on AIX if only because there was CICS for AIX available (maybe still is? Paradoxically it was easier for me to get the mainframe version running... than any AIX system...)

MicroFocus on RHEL is stuff I've seen live recently, including new development, and I think there are still companies buying new releases of COBOL programs.

Similarly, MUMPS is very much alive in financial market, with completely new development being done even if mostly as small component of biggerz usually Java apps

Re: 20 Years in the Making, GnuCOBOL Is Ready for Industry

#86

Post by __d »

fredsmith219 wrote: post #5

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.

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?

Re: 20 Years in the Making, GnuCOBOL Is Ready for Industry

#87

Post by rgmerk »

lupire wrote: post #36
ajxs wrote: post #13

Earlier quoted context omitted.

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…

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?

Most of these systems are likely software ships of Theseus.

Very few lines of code will be unmodified from their original state, but at any given point in time the changes required will only have been small.

Hence it’s always been a pragmatic choice to do small modifications rather than a ground-up reimplementation.

Re: 20 Years in the Making, GnuCOBOL Is Ready for Industry

#88

Post by NikolaNovak »

ajxs wrote: post #81
miki123211 wrote: post #47

Earlier quoted context omitted.

The world changes little-by-little, not all at once. Let's say your application (100k LoC of Cobol) handles payroll. Your government introduces some new rules about how paternity leave should be handled. You have two options, rewrite the 100K lines into Java and add the new rule, or just add the new rule in the Cobol app. The latter is cheaper, at least in the long term, so that's what you do. Now you have 101k lines…

I've worked at organisations which have mainframe applications that have been running for almost 50 years. One of the funnier reasons I've heard about why these '100k lines of COBOL' programs never get rewritten is that no one really knows the full extent of what they do, and even if they do know the full extent of what they do, no one really knows the full extent of why . The business requirements that these program…

It is a 100% true anecdote at any number of businesses. It's philosophically enlightening in a way and related to an increasingly profound adage of "Purpose of the system is what it does" (which can be applied to IT and political and social and school and other systems through various lenses).

There are any number of systems out there which are "self documenting" in a weirder sense that what they do is what the rules are, rather than other way around. There's no external document or business process ruleset that describes what they do at the level of detail and accuracy that code does. There are a myriad edge cases built in which are important and relevant and likely still true (until somebody actively decides to change some rules) but not well documented or understood. I'm working on a government payroll system and it is mind.boggingly more complex than ever I could have possibly imagined and it still blows my mind every day. We have tens of thousands of time & labour rules due to hundred unions making thousands of negotiations over decades, on top of complex baseline payroll and taxation rules across governments and provinces and levels.

Attempts to rewrite such a software almost always, almost inevitably, take much longer and cost much more not just because of technical and architectural challenges, but because of, well, hubris - assumption that just because we can migrate webserver code across platforms, we can migrate a payroll system across platforms as well. Turns out one is orders of magnitude more complex than the other, we are just not used to thinking that way :).

Re: 20 Years in the Making, GnuCOBOL Is Ready for Industry

#89

Post by NikolaNovak »

mardifoufs wrote: post #69
NikolaNovak wrote: post #33

Earlier quoted context omitted.

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:)

Is it hard to recruit younger devs? Also, I heard that the hard part of using Cobol is that almost every one uses a different "flavor" of Cobol, with different tool chains and most of the ecosystem is proprietary. Is that still true?

It's true, but way less true than for any other modern programming language I've seen today with our fancy frameworks and models and libraries and methodologies changing radically every 12 minutes :).

That being said, the hard part of COBOL is not COBOL, or even tools/framework. Hard part of COBOL is that it's primarily a business language, as per name. If you're coding in COBOL, you're unlikely to be developing a new webserver or compiler or webpage or whatnot. You are unlikely to be focusing on technology and agnostic to the business domain it's supporting: In fact, you're coding key critical business logic, so you really need to be 30% good at COBOL, and 70% good at understanding business, talking business requirements, and eliciting business requirements from extremely non-programing people.

Again, cannot speak for the full COBOL ecosystem, but I have never recruited a "COBOL person for just COBOL" (other shops I'm sure have). It's something that sneaks up on you - maybe it's one of 3-4 things you need to work on a new job, or maybe there's an emergency legislative change and James is on vacation so Fatima looks at the COBOL program and changes a simple tax formula on it, and bam, now Fatima is the local COBOL guru and gets more and more COBOL assignments until she is de facto actual COBOL expert :).

More specifically, I have worked over my career on a lot of PeopleSoft systems - ERP applications for Payroll, Finance, CRM, EPM, etc. Almost all languages in it are if not proprietary, than weird and unknown to HN audience: PeopleSoft and PeopleCode application engine, SQR (Structured Query Reports) and COBOL. The application itself is made in standard languages, but updating and customizing the business logic for decades of ownership is primarily in those 4 languages. So you don't become a COBOL developer, you become a PeopleSoft developer and COBOL is one of the pillars of it. Thus, I don't hire COBOL developers, I hire PeopleSoft developers.

Hope that helps :)

Re: 20 Years in the Making, GnuCOBOL Is Ready for Industry

#90

Post by pjmlp »

_hcuq wrote: post #14
NikolaNovak wrote: post #6

>>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…

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

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