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

111–118 of 118 posts

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

#111

Post by simne »

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 just not that amazing compared with modern alternatives

To be honest, I'm new in field of mainframes, I'm just few weeks playing with Hercules.

But, after more than 20 years in industry, on micro- level (I near all my life spent with all sorts of x86 and with networking hardware, but also few years with Macs and with microcontrollers), I must say, only thing comparable to mainframes in reliability is Erlang.

And if I will take your words, just replace with regex /cobol/erlang/i, most will become truth, because, Erlang have much less LOC numbers, but looks like cost of massive reliability is same - not easy to write, or maintain (it is just too different from classic modern programming way), also Erlang is not very fast (experienced people said, it is close to Perl).

All these matter even considering Erlang syntax directly derived from Prolog, nearly best syntax in the modern world!

BTW if you want, I'm open to talk about how to make Erlang better for today, or even, talk possible ways to engage COBOL with Erlang on modern hardware.

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

#112

Post by simne »

simne wrote: post #111
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 just not that amazing compared with modern alternatives To be honest, I'm new in field of mainframes, I'm just few weeks playing with Hercules. But, after more than 20 years in industry, on micro- level (I near all my life spent with all sorts of x86 and with networking hardware, but also few years with Macs and with microcontrollers), I must say, only thing comparable to mainframes in reliability is Erlan…

BTW you could consider me guy from Philippe Kahn world (I begun with Turbo C and Turbo Pascal, than was Delphi, eventually Modula, other pillar of reliable world).

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

#113

Post by simne »

cwbriscoe wrote: post #76
chasil wrote: post #40

Earlier quoted context omitted.

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

This is actually the first time I have heard of SQL/PSM. From Wiki, looks like it is for stored procedures. We do not do stored procedures at all on our DB2 instances. Heck, we don't even use triggers either. All our mainframe/DB2 business logic is in COBOL.

Wow! I've worked with SMS sending gateway and cofounders cannot avoid temptation to use stored procedures for logic (we use Postgres, and logic in Perl). Because of this, last years installations limited by HDD performance, but fortunately, after crisis of 2008, we don't need much scaling.

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

#114

Post by simne »

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…

> IBM mainframes have five nines of availability

This is incredible. I miss that time, when seen with naked eye difference of reliability of mainframes.

Now, I know many organizations using Erlang/OTP or Java EE, and mostly think them good enough comparable to mainframes environment and few times cheaper.

BTW Erlang in British Telecom achieve five nines reliability.

But must admit, Erlang/Java are not best suited for finance/lawyer applications, and I don't hear about finance/law libraries for Erlang, so this could be issue (or opportunity for somebody, depend on how you look on it).

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

#115

Post by simne »

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

IBM hardware is reliable, BUT, IBM avoid to go to airspace industry as flight computer supplier.

After Saturn-5, flight computers made by other companies. Its hard to understand, if this is because conservative regulations, or because not enough money for such big company, but fact, that IBM electronics near absent from large civilian airplanes.

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

#116

Post by musicale »

skissane wrote: post #109
guenthert wrote: post #83

Earlier quoted context omitted.

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

> 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 Java does math the same way as COBOL does math, if you use java.math.BigInteger, java.math.BigDecimal, javax.money, etc Unlike (say) C++ or C#, Java doesn't have operator overloading, so BigInteger/BigDecimal/etc don't let you use ordinary oper…

I like decimal math, and I don't think it's well supported in many languages.

I also like AppleScript's crazy English (or French or Japanese) syntax, and I can't help but wonder if it (and HyperTalk) were partially inspired by COBOL.

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

#117

Post by simne »

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 so much

Yes and no. Really, developed world have very stable laws, this is one of pillars of power.

So, new companies, like Uber, Apple (appstore), Microsoft (when created XBox), etc, sure have to create new infrastructure from scratch, because their new vision is their concurrent advantage.

But, for old businesses, like financial, energy, some others, most important to use all measures to cut transaction costs, and they achieve this by reusing old information infrastructure (not only this, but this is important part of equation). Unfortunately for old big businesses, their business models created when only mainframes could withstand their scale (clouds with micro- become mature enough, I think in 1990s; mini's just not considered as replacement of big machines), so big companies have large heritage on mainframes.

I know few cases, when large company move their infrastructure to cloud, but as I know, they mostly prefer to remain with old but reliable mainframes if possible.

At end of my speech I could add, I myself could be considered hunter from micro-world, who hunt for people who wish to switch (to micro and clouds), so I really know how much it cost :)

But to be honest, I feel romantic feelings to mainframes, as they are important part of history, I think we should save them for future generations.

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

#118

Post by vram22 »

p_l wrote: post #85
vram22 wrote: post #62

Earlier quoted context omitted.

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

Interesting about MUMPS.
Post reply on HN