I award them no points, and may God have mercy on their souls.
20 Years in the Making, GnuCOBOL Is Ready for Industry
51–60 of 118 posts
Re: 20 Years in the Making, GnuCOBOL Is Ready for Industry
#52Earlier 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…
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.
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 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.
Re: 20 Years in the Making, GnuCOBOL Is Ready for Industry
#53Earlier quoted context omitted.
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.internetne…
What they got from EnterpriseDB is the Oracle (PL/SQL) compatibility. SQL/PSM was built by IBM themselves.
Re: 20 Years in the Making, GnuCOBOL Is Ready for Industry
#54Earlier quoted context omitted.
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.
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.
Re: 20 Years in the Making, GnuCOBOL Is Ready for Industry
#55Earlier quoted context omitted.
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... Europea…
The MAX was certified less than 2 months after Trump took office. He had nothing to do with it.
Re: 20 Years in the Making, GnuCOBOL Is Ready for Industry
#56Earlier 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.
That sounds like a shit bank. I can recall only a single system-level outage at my bank in 20 years.
Re: 20 Years in the Making, GnuCOBOL Is Ready for Industry
#57Don’t miss the GnuCOBOL FAQ and How To, perhaps one of the largest such documents ever compiled:
https://gnucobol.sourceforge.io/faq/index.html
(may cause mobile browsers to crash while loading)
Re: 20 Years in the Making, GnuCOBOL Is Ready for Industry
#58I award them no points, and may God have mercy on their souls.
This 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.
Re: 20 Years in the Making, GnuCOBOL Is Ready for Industry
#59>>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…
The punched card reference is most apt for COBOL, reason being the formatting and those limits dictated the column restrictions - hence COBOL historically had 80 columns max, and code sure does legacy when it's that mature.
Re: 20 Years in the Making, GnuCOBOL Is Ready for Industry
#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