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

41–50 of 118 posts

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

#41

Post by NikolaNovak »

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?

That's a very techie view (and I speak as, largely, one:)

Core accounting principles don't change so much. Core payroll principles don't change so much. Core finance principles don't change so much.

We have a technology-oriented view that "world changes so much", but there are domains where that's true, and domains where that's not true.

Several times in my life I had the luck to have a mentor ask me, when I propose some obvious technological change and improvement, "what's the business advantage? If I let you spend X amount of hours over Y days to accomplish technical change Z, in which way will the business be better?"

In the world of startups and ___-tech, technology stacks matters and change and it's a whirlwind world of frameworks and languages and webapps stuff.

But in the core, back-office, cost-centre business of the company... the rules are complicated and numerous but in a way stable enough that solid stable complex software from 30 years ago still has value.

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

#42

Post by lupire »

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…

Modern cloud backend data processing is 5 9s reliable too, for very core stuff, not all the app frontends and minor features.

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

#43

Post by 7thaccount »

musicale wrote: post #28

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

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.

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

#44

Post by chasil »

cwbriscoe wrote: post #31
smackeyacky wrote: post #12

Earlier quoted context omitted.

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.

I have heard horror stories about IMS but have been fortunate to never have to use it. DB2 is pretty decent and very reliable.

IMS is a hierarchical database.

Under OS2200, DMS is also a hierarchical database, and (unfortunately) we use it.

My developers have described it as the Fort Knox of databases, being very difficult to get data out.

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

#45

Post by chasil »

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

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

#46

Post by shrubble »

lupire wrote: post #42
slt2021 wrote: post #25

Earlier quoted context omitted.

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…

Modern cloud backend data processing is 5 9s reliable too, for very core stuff, not all the app frontends and minor features.

You don't even have the assurance that the RAM is ECC on cloud...

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

#47

Post by miki123211 »

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?

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

20 years, four tax reforms, three mergers, five international expansions and fifty lawsuits later, you have migrated 100k lines of Cobol to Java, but your app grew and is now 3 million lines.

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

#48

Post by miki123211 »

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…

And yet my bank very regularly goes down for (scheduled) technical maintenance.

Most mom-and-pop stores running Wordpress on shared PHP hosting are more reliable than that.

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

#49

Post by asp_hornet »

lupire wrote: post #42
slt2021 wrote: post #25

Earlier quoted context omitted.

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…

Modern cloud backend data processing is 5 9s reliable too, for very core stuff, not all the app frontends and minor features.

Modern cloud “5 nines” isnt a promise of availability but a promise to get some store credit each month when it inevitably fails (adjusted down for usage because you dont use all that capacity you pay for so we just credit for the percentage you do).

The trick is to make sure when you promise 5 9s to your customer that you build in the same bullshit clauses so you dont get left holding the bag.

Its gross

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

#50

Post by YeGoblynQueenne »

cwbriscoe wrote: post #29
guestbest wrote: post #16

Earlier quoted context omitted.

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.

Yes, but you use the REXX to generate the JCL.
Post reply on HN