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

31–40 of 118 posts

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

#31

Post by cwbriscoe »

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.

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

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

#32

Post by foobarian »

Affric wrote: post #30
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…

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.

And your comment just made me wonder if the two recent Boeing crashes actually mean the IBM hardware is even *more* reliable

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

#33

Post by NikolaNovak »

iopq wrote: post #24
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!

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

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

#34

Post by slt2021 »

foobarian wrote: post #32
Affric wrote: post #30

Earlier quoted context omitted.

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.

And your comment just made me wonder if the two recent Boeing crashes actually mean the IBM hardware is even *more* reliable

recent scandals with Boeing and United is the result of trump deregulating airlines. https://www.npr.org/2020/12/03/942345240/trump-administratio...

a lot of regulation just became "self-certify" and companies obviously cut costs and outsourced everything including fleet maintenance.

this article is from 2015 - but things got way worse since then https://www.vanityfair.com/news/2015/11/airplane-maintenance...

European airlines and Airbus are flying just fine, it is Americans that have a problem due to over politicized and polarized society and corrupt politicians

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

#35

Post by NikolaNovak »

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

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

#36

Post by lupire »

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

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

#37

Post by NikolaNovak »

airstrike wrote: post #10
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…

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

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

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

#38

Post by [deleted] »

cwbriscoe wrote: post #27
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…

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

[deleted]

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

#39

Post by 7thaccount »

_huayra_ wrote: post #18
chasil wrote: post #17

Earlier quoted context omitted.

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

Are you able to find COBOL programmers to hire, or is it like Rust where a lot of jobs are "know C++ and we'll train you"?

My buddy's wife has a business degree and her first company had her learn Cobol for a couple of months (never had programmed before). I'm not sure where that went after the training, but apparently it's still a thing (this was only a few years ago).

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

#40

Post by chasil »

cwbriscoe wrote: post #27
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…

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

Db2 actually implements SQL/PSM, which is more than can be said for Sybase/Microsoft SQL Server.

I'm not sure if this extends to all three Db2 variants, namely Mainframe, AS/400 derivatives, and UDB for Linux and Windows (I hope so).

https://en.m.wikipedia.org/wiki/SQL/PSM

IBM supposedly got the PSM code from EnterpriseDB/Postgres.

https://www.enterprisedb.com/news/enterprisedb-and-ibmr-coll...

https://www.internetnews.com/blog/ibm-gets-compatible-with-o...

Post reply on HN