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

61–70 of 118 posts

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

#61

Post by vram22 »

Zenst wrote: post #60

"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

>I'd love to read more about that aspect

See the

  DATA DIVISION. 

  FILE SECTION.

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

#62

Post by vram22 »

p_l wrote: post #20
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…

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

And on Xenix earlier, and on SVR4 and SVR3.

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

#64

Post by [deleted] »

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

[deleted]

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

#66

Post by inkyoto »

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…

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

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

#67

Post by slt2021 »

miki123211 wrote: post #54
YeGoblynQueenne wrote: post #52

Earlier quoted context omitted.

It's the servers that go down! Not the 'frames. Those will go down maybe once a year for maintenance, if that. The mainframe engineers will brag your ears off about that and about the unreliability of the "distributed" systems (a.k.a. servers, a.k.a. what everyone else uses). When you log on to your online banking you're interacting with servers, not with the mainframes directly. The servers are the interface, the ma…

I definitely remember my bank warning me about credit and debit card unavailability, so it's definitely not just the online systems. If cards don't work and the online systems don't work, I don't know what else does. Those maintenance periods usually happen at night, so branches aren't open and wire transfer systems don't work.

Maybe your bank goes down, but the Visa and Mastercard systems have been processing card payments 24/7 non stop and I dont even remember hearing a single incodent when system was down even partially

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

#68

Post by cwbriscoe »

YeGoblynQueenne wrote: post #50
cwbriscoe wrote: post #29

Earlier quoted context omitted.

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.

Hmm. I guess I am just not seeing the use case but not saying there isn't one. JCL, isn't hard to do. You usually just copy 80% of it from other jobs and change dataset names, etc...

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

#69

Post by mardifoufs »

NikolaNovak wrote: post #33
iopq wrote: post #24

Earlier quoted context omitted.

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

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?

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

#70

Post by chungy »

Zenst wrote: post #60

"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

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.
Post reply on HN