71–80 of 118 posts
That 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.
>>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…
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…
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…
COBOL 2022. My god.
Earlier 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…
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'd love to know more about why someone would choose COBOL today, if anyone can fill me in. I doubt anybody is choosing to start a new greenfield system in COBOL in 2024. But, if you have an existing COBOL code base, and the business is asking for new features, you have two basic choices (1) write new modules for the existing system in COBOL (2) write the new modules in a more mainstream language (Java, C#, whateve…
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.
Your bank might have meant card balances being unavailable in the online banking which is more plausible than cards being generally unavailable for payments. It is not indicative of the mainframe actually being down (although not entirely improbable, either), and it is more likely that an intermediary (a service or a server) was undergoing maintenance.
Payment processing involves multiple tiers and multiple routing layers built into it – to ensure very high availability and that a payment is almost always guaranteed to process (successfully or otherwise – does not matter). Payment networks also impose stringent technical requirements onto the banks connecting to them. A Raspberry Pi running Slackware Linux from 1993 and powered by a dangling street pole wire would not be allowed to connect, for example.
Your bank (or mine, for the sake of the conversation) is the terminal point in this whole payment processing chain, with the payment network (Visa, Mastercard but not AmEx[0]) being the port of entry for a payment. Depending on the country, a country may have its own local payment Visa / MC processing centre and if that is the case, local payments will be routed to the local card payment processor. Otherwise, a global Visa/Mastercard will assume the payment. Then the payment network contacts your local bank to authorise the payment. Depending on the nature of the failure + other factors, the Visa/Mastercard can authorise certain payments on behalf of your bank if they fail to reach your bank and will forward the payment particulars onto your bank so that your bank could correctly process your card payment later. It is more common in overseas payment scenarios, i.e. you are travelling overseas and especially so when travelling outside the first world countries.
Payment networks and banks do not like such situations and actively loathe non-real time payment authorisations, yet they allow them for a narrow number of use cases at their own discretion.
[0] AmEx own their own global payment network and do not allow other financial institutions to gain access into it.
In 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…
The "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-hold...
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.