20 Years in the Making, GnuCOBOL Is Ready for Industry • Hacker News Board

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

#21

Post by Borborygymus » Sat, Mar 16, 2024, 11:23 PM UTC

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.

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

#22

Post by macintux » Sat, Mar 16, 2024, 11:31 PM UTC

smackeyacky wrote: post #12

macintux wrote: post #8

Earlier quoted context omitted.

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?

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.

You just reminded me that in the mid-90s I took a TCP/IP workshop where the other attendees worked on mainframes. The chasm between what I was familiar with and what they were was impressively wide.

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

#23

Post by skissane » Sat, Mar 16, 2024, 11:32 PM UTC

ajxs wrote: post #13

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…

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

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

#24

Post by iopq » Sat, Mar 16, 2024, 11:41 PM UTC

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…

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

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

#25

Post by slt2021 » Sat, Mar 16, 2024, 11:54 PM UTC

foobarian wrote: post #9

proneb1rd wrote: post #3

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

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.

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

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

#26

Post by mseepgood » Sun, Mar 17, 2024, 12:12 AM UTC

What took so long?

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

#27

Post by cwbriscoe » Sun, Mar 17, 2024, 12:15 AM UTC

ajxs wrote: post #13

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…

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…

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.

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

#28

Post by musicale » Sun, Mar 17, 2024, 12:18 AM UTC

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

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

#29

Post by cwbriscoe » Sun, Mar 17, 2024, 12:20 AM UTC

guestbest wrote: post #16

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.

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

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.

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

#30

Post by Affric » Sun, Mar 17, 2024, 12:20 AM UTC

slt2021 wrote: post #25

foobarian wrote: post #9

Earlier quoted context omitted.

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.

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

lol… this comment just makes me remember that how likely you are to die is determined by an estimate of what a company can get away with by an actuary.