3 ms·

As always, these discussions will depend on your definition of "dead" and "alive". If we can call a technology dead once no new business is built on it, then I

As always, these discussions will depend on your definition of "dead" and "alive". If we can call a technology dead once no new business is built on it, then I think we can safely call COBOL dead (and the IBM 390x aka Z/OS platform along with it, for which "COBOL" is usually a proxy). But if we say that anything still being used in production is not dead, then of course COBOL is alive and significantly more alive than many other things which are younger than it. But this shouldn't really be taken as a positive point for COBOL or the mainframe ecosystem. It's simply a fact of life that organizations tend to stick with the first thing that works, and for the types of entities involved in the first wave of digitalization (e.g. governments, banks, airlines) that was usually an IBM mainframe along with the software that runs on it.

DaiPlusPlus 2y ago
> we can call a technology dead once no new business is built on it You don’t suppose any bank - or other large financial institution - might have standardised on Cobol for their core business flows/processes? In which case a new business-unit or “internal startup” team (e.g. a new category of insurance product) might very-well have some part written in Cobol so it integrates with the rest of the bank - or at very-least might be built-on-top of the org’s existing Cobol-running infrastructure (i.e. Not written in Cobol, but still runs on Z/OS because there’s no budget for buying new commodity x86 racks and the people to manage and run them).
- snovymgodym 2y ago
  Sure, I know for a fact that what you're describing exists. That's not really what I mean by new business being built on it. That's a case of a very large and old business already being so locked into the mainframe ecosystem for their core systems that anything new they try to do ends up needing some kind of integration system with the legacy system. What I mean is that nobody starts a business today and says "Ok, we need an IBM mainframe running DB2 and we'll have a bunch of COBOL, ReXX, and PL/I programs for handling our business logic".
  - zifpanachr23 2y ago
    There was a decent amount of that going on in China in the 90s and early 2000s actually in the banking sector. You probably won't see much "new business" until you see companies in new large markets explode in size. As in you are unlikely to ever see "new business" in the US, because you'd need a new bank or something to somehow explode to the size of one of the big four and suddenly realize they need to get on board with what all the competition is doing in order to compete. But it has happened at least a little within the past couple of decades, most notably with China but there have probably been other examples in Asia.
- makeitdouble 2y ago
  I was under the impression that banks with core COBOL processes all had an intermediate layer in Java/C# to deal with these kind of integration. We saw exactly the case of a new business unit being created, and like most other units it wouldn't get direct access to the lowest layer, and interact instead with a saner level of API and modules in the language of their stack.
  - jamesfinlayson 2y ago
    Yeah that my impression too - I haven't worked in banking but I've worked at a few places with core functionality written in Fortran and then web-facing API layers on top of that (some was in Java in think).
calibas 2y ago
COBOL is undead.
8fingerlouie 2y ago
> and the IBM 390x aka Z/OS platform along with it The problem with killing the mainframe is that no other platform really exists that can handle the amount of simultanous IO that you can get on a mainframe. Our mainframe easily processes 100m transactions per hour, with room to spare. And keep in mind that those transactions are for the most part synchronous, and will result in multiple SQL transactions per transaction. Yes, eventual consistency is a thing, but it's a very bad match with the financial world at least, and maybe also military, insurance or medical/health. You can of course also partition the workload, but again, that creates consistency issues when going across shards. Also, COBOL is far from dead, but it's slowly getting there. I don't know of a single bank that isn't actively working on getting out of the mainframe, though all projections i've seen says that the mainframe and COBOL will be around until at least 2050. Give that a thought. That's 26 years of writing COBOL. Considering that COBOL programmers are also highly sought after, and usually well paid, one could literally still begin a career as a COBOL programmer today and almost get a full work life worth of it.
zifpanachr23 2y ago
If by new business we literally mean startups, then that has been the case basically forever, even back in the 60s and 70s. Mainframes were never really for new businesses in the startup sense of the word. The barrier to entry has always been kind of extreme. So the big customers even back in the day were always old insurance companies and banks and governments etc. It wasn't really until minicomputers that "new businesses" doing computing at all was feasible. So in that sense, not much has really changed, and for the target market of the product, I don't think it makes sense as a good metric for whether the platform is dead or alive.

DaiPlusPlus 2y ago

> we can call a technology dead once no new business is built on it You don’t suppose any bank - or other large financial institution - might have standardised on Cobol for their core business flows/processes? In which case a new business-unit or “internal startup” team (e.g. a new category of insurance product) might very-well have some part written in Cobol so it integrates with the rest of the bank - or at very-least might be built-on-top of the org’s existing Cobol-running infrastructure (i.e. Not written in Cobol, but still runs on Z/OS because there’s no budget for buying new commodity x86 racks and the people to manage and run them).

snovymgodym 2y ago
Sure, I know for a fact that what you're describing exists. That's not really what I mean by new business being built on it. That's a case of a very large and old business already being so locked into the mainframe ecosystem for their core systems that anything new they try to do ends up needing some kind of integration system with the legacy system. What I mean is that nobody starts a business today and says "Ok, we need an IBM mainframe running DB2 and we'll have a bunch of COBOL, ReXX, and PL/I programs for handling our business logic".
- zifpanachr23 2y ago
  There was a decent amount of that going on in China in the 90s and early 2000s actually in the banking sector. You probably won't see much "new business" until you see companies in new large markets explode in size. As in you are unlikely to ever see "new business" in the US, because you'd need a new bank or something to somehow explode to the size of one of the big four and suddenly realize they need to get on board with what all the competition is doing in order to compete. But it has happened at least a little within the past couple of decades, most notably with China but there have probably been other examples in Asia.
makeitdouble 2y ago
I was under the impression that banks with core COBOL processes all had an intermediate layer in Java/C# to deal with these kind of integration. We saw exactly the case of a new business unit being created, and like most other units it wouldn't get direct access to the lowest layer, and interact instead with a saner level of API and modules in the language of their stack.
- jamesfinlayson 2y ago
  Yeah that my impression too - I haven't worked in banking but I've worked at a few places with core functionality written in Fortran and then web-facing API layers on top of that (some was in Java in think).

calibas 2y ago

COBOL is undead.

8fingerlouie 2y ago

> and the IBM 390x aka Z/OS platform along with it The problem with killing the mainframe is that no other platform really exists that can handle the amount of simultanous IO that you can get on a mainframe. Our mainframe easily processes 100m transactions per hour, with room to spare. And keep in mind that those transactions are for the most part synchronous, and will result in multiple SQL transactions per transaction. Yes, eventual consistency is a thing, but it's a very bad match with the financial world at least, and maybe also military, insurance or medical/health. You can of course also partition the workload, but again, that creates consistency issues when going across shards. Also, COBOL is far from dead, but it's slowly getting there. I don't know of a single bank that isn't actively working on getting out of the mainframe, though all projections i've seen says that the mainframe and COBOL will be around until at least 2050. Give that a thought. That's 26 years of writing COBOL. Considering that COBOL programmers are also highly sought after, and usually well paid, one could literally still begin a career as a COBOL programmer today and almost get a full work life worth of it.

zifpanachr23 2y ago

If by new business we literally mean startups, then that has been the case basically forever, even back in the 60s and 70s. Mainframes were never really for new businesses in the startup sense of the word. The barrier to entry has always been kind of extreme. So the big customers even back in the day were always old insurance companies and banks and governments etc. It wasn't really until minicomputers that "new businesses" doing computing at all was feasible. So in that sense, not much has really changed, and for the target market of the product, I don't think it makes sense as a good metric for whether the platform is dead or alive.