18 ms·
20 Years in the Making, GnuCOBOL Is Ready for Industry
- ddgflorida 3y agoWell that's exciting :)
- proneb1rd 3y agoVery exotic. Does it support multi threading? What kind of things can be done with it?
- foobarian 3y agoI'm guessing it does money math in a certain way vetted by this field that would be very difficult to recertify on some replacement.
- airstrike 3y agoFor some value of "very difficult"
- slt2021 3y agonot 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
- salawat 3y ago...that wasn't made by Boeing in the last 20 years.
- simne 3y ago> 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).
- Affric 3y agolol… 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.
- foobarian 3y agoAnd your comment just made me wonder if the two recent Boeing crashes actually mean the IBM hardware is even *more* reliable
- simne 3y agoIBM 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.
- slt2021 3y agorecent scandals with Boeing and United is the result of trump deregulating airlines. https://www.npr.org/2020/12/03/942345240/trump-administrations-new-regulation-favors-airlines-at-travelers-expense 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-disturbing-truth 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
- ralph84 3y agoThe MAX was certified less than 2 months after Trump took office. He had nothing to do with it.
- 3y ago
- lupire 3y agoModern cloud backend data processing is 5 9s reliable too, for very core stuff, not all the app frontends and minor features.
- shrubble 3y agoYou don't even have the assurance that the RAM is ECC on cloud...
- asp_hornet 3y agoModern 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
- miki123211 3y agoAnd 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.
- YeGoblynQueenne 3y agoIt'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 mainframe is the, let's say far back end. That will be handling millions of transactions a second while the servers are down for maintenance- like handling payments and transfers etc, not just online banking. Which is why it can't keep failing every few months or so.
- miki123211 3y agoI 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.
- YeGoblynQueenne 3y agoI don't know the particulars about your bank, obviously but the thing is, mainframes serve so many millions of clients, and that's clients of the largest money transfer networks (Amex, Visa, Master, everyone really) that if there's an outage it will make the news, internationally, and it will be front page news too. With live updates. In fact, if I think about it, I don't think I remember any time when a serious outage that was eventually explained in the press was the fault of some mainframe going down. Usually it's something else, like someone misconfigured something or something didn't update correctly etc. stuff that sounds a lot like day-to-day web dev stuff. So I think maybe it was something else that went on with your bank, that only affected your bank. Like inkyoto says below, maybe some DNS went down?
- seanhunter 3y agoBut you need a modern enterprise-quality framework. Can it run Cobol on Cogs? http://www.coboloncogs.org/INDEX.HTM http://www.coboloncogs.org/INDEX.HTM
- fredsmith219 3y agoThe 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.
- macintux 3y agoI’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?
- smackeyacky 3y agoFrom 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.
- macintux 3y agoYou 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.
- cwbriscoe 3y agoI have heard horror stories about IMS but have been fortunate to never have to use it. DB2 is pretty decent and very reliable.
- chasil 3y agoIMS 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.
- NikolaNovak 3y ago>>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 Linux).
- airstrike 3y agoLet us join hands in a moment of silent prayer for those unfortunate souls
- NikolaNovak 3y agoEh. There are ways in which their lives are easier and more zen :)
- ajxs 3y agoI'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 the most battle-tested things in existence, and do what they do very well. I've seen them in action personally. However I'm also under the impression that COBOL is just not that amazing compared with modern alternatives: It's not easy to write, or maintain, and (as far as I understand) the things that make it 'fast' have more to do with the platform than COBOL itself. I'd love to know more about why someone would choose COBOL today, if anyone can fill me in.
- simne 3y ago> 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.
- rhaps0dy 3y ago> the past three years, it has received attention from 13 contributors with 460 commits. That doesn’t sound like very many commits. Pretty mature!
- Borborygymus 3y agoIn 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.
- chasil 3y agoThe "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-holding-you-hostage-with-math-5498c0eb428b https://medium.com/the-technical-archaeologist/is-cobol-hold...
- vesinisa 3y agoI hate that it's spam-walled but that Medium article sure was a riveting read. Basically the conclusion is that for mainframe systems that need to process lots of transactions fast the performance of COBOL is hard to beat. Languages like Java are not even very well suited for these type of calculations since BigDecimal is not part of the core programming idiom. With the additional cost that migration would carry, it's actually less risky and more cost effective to keep maintaining the COBOL system, even if it means paying in-house to train programmers in this ancient technology.
- mseepgood 3y agoWhat took so long?
- Pokerface777 3y ago[flagged]
- musicale 3y agoCOBOL's boilerplate doesn't seem that much worse than what Java programmers lived with for decades.
- 7thaccount 3y agoThe 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.
- ngcc_hk 3y agoThey are both verbose. But cobol is more data definition oriented.
- xunil2ycom 3y agoI award them no points, and may God have mercy on their souls.
- asp_hornet 3y agoThis exists because most modern rewrites of COBOL systems have been rewritten several times over despite the rewrites never finishing all the functionality of the original. Modern day software engineers need to eat a huge slice of humble pie.
- michaelsbradley 3y agoDon’t miss the GnuCOBOL FAQ and How To, perhaps one of the largest such documents ever compiled: https://gnucobol.sourceforge.io/faq/index.html https://gnucobol.sourceforge.io/faq/index.html (may cause mobile browsers to crash while loading)
- Zenst 3y ago"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
- vram22 3y ago>I'd love to read more about that aspect See the DATA DIVISION. FILE SECTION.
- chungy 3y agoFrom 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.
- pjmlp 3y agoSame applies to SQL, FORTRAN, JSEngines, POSIX, even C and C++ compilers, if you bother to go through all the little letters legalese on the standards and cross check with their latest implementations, outside the big three it is even worse. It appears everyone only strives with good enough, fine tunes with bug reports for lesser known features and that is about it.
- zulban 3y agoThat hello world program is brutal. Truly, the language is the first of its kind. Hopefully this helps fleets of developers bring their legacy code (more legacy than most of us can imagine) into a modern stack, and start applying modern SWE principles to it.
- magpi3 3y agoIt's logical and it makes sense. I would argue, at first glance, that C's hello world (#include <stdio.h>, int argc, char ** argv, etc) would be more confusing to a total newbie. Java's even more so.
- globalnode 3y agoone of my subjects at uni in the 90's (IT degree) required me to learn cobol. god i hated that class. thankfully i dont remember much of it. it was actually before we learn't c/c++, also VB was a big thing then too.
- nxobject 3y ago> There’s no support yet for objects or messages in GnuCOBOL. > Objects was “a nice feature from COBOL 22, which isn’t used that much,” Sobisch said. > Messaging just got reimplemented recently, and is still a new feature for the COBOL crowd to grapple with, Sobisch said. So, no support in GnuCOBOL yet. COBOL 2022. My god.
- mise_en_place 3y agoIt’s interesting but will anyone actually use it? z/OS for example doesn’t have a hierarchical file system. The version of COBOL they bundle supports data sets I’d imagine. Legacy folks will be hesitant to switch to it as well. When I worked at a bank they couldn’t even use the latest Java, due to compliance and regulatory reasons.