The reason mainframe persists is it's a pretty slick development and deployment environment. A lot things you might cobble together as dependencies - like maybe a database or a message queue, or observability facilities or even deployment strategies like hot-hot deployments - they're all just built in to the platform. That means they're trivial to consume and they're fully supported by one vendor. It's like the world…
Most of this Cloud technology we like to go all atwitter about is a retread or a redesign of software that's been on mainframes for thirty years. The old farts must laugh themselves silly looking at us acting like we discovered a large white object orbiting the earth.
The IBM mainframe: How it runs and why it survives
101–110 of 195 posts
Re: The IBM mainframe: How it runs and why it survives
#102Earlier quoted context omitted.
> It persists in many places due to the deeply ingrained belief that, for one reason or another, it would be technically, practically, or economically impossible to migrate functionality off the mainframe. It is never technical or pratical reasons, always economic reasons. To use contemporary vocabulary, you "just" need to replicate a "multi tenant HA cloud environment" to migrate from a mainframe at great cost. > An…
>most of the business software that goes into said mainframe is in fact very simple and straightforward Yeah no. I worked on mainframe code for 15 years of the last 20 and can tell you that you’re wrong. Even reasonably simple business lines have cobbled together insane cobol, batch and cics screens that would make spaghetti blush. When you open up a 100,000 line batch program that’s just 1 of 30 cobol programs in th…
how do you know?
Re: The IBM mainframe: How it runs and why it survives
#103Earlier quoted context omitted.
>most of the business software that goes into said mainframe is in fact very simple and straightforward Yeah no. I worked on mainframe code for 15 years of the last 20 and can tell you that you’re wrong. Even reasonably simple business lines have cobbled together insane cobol, batch and cics screens that would make spaghetti blush. When you open up a 100,000 line batch program that’s just 1 of 30 cobol programs in th…
What happens when there are new requirements? An example, fiscal legislation changes and programs dealing with money have to adapt. Of course a way out is to lobby for changes that don't touch the software, but what happens when the software must be touched?
Edit: and for the record, at that point, we were already splitting off carbon transactions for their own processing because, surprise, energy has lots of regulation.
Re: The IBM mainframe: How it runs and why it survives
#104Earlier quoted context omitted.
But let's say you want that data compressed and/or encrypted, you're going to need an awful lot of compute to exploit that 48GB/s if it's possible at all. Whereas on mainframe the service processors can deal with it transparently to the CPU using specialized hardware. And let's say it's financial transactions - fixed-point decimal arithmetic. On mainframe, that can be hardware accelerated too.
Yes, and it's interesting how Intel is moving in that direction with their Xeon line, integrating the QAT peripheral for compression and encryption offloading. Unfortunately these things are unicorns and that aren't generally available in the cloud, either.
Re: The IBM mainframe: How it runs and why it survives
#105Re: The IBM mainframe: How it runs and why it survives
#106Earlier quoted context omitted.
Well, for one, lack of capable personnel. Nobody learns IBM Mainframes in school, and most jobs for them want experience. Furthermore, they're not sexy but boring, with paywalled docs and similar shitty "enterprise" techniques, making it so very few people actually want to or manage to learn them. And it's a dead end, career-wise (very few companies use them, so changing jobs isn't as easy as more widely used tech).…
Completely untrue. Listen to everything Cameron Seay has ever said about the subject. Mainframe programmers are wanted more than ever. https://www.youtube.com/watch?v=hxxyORcU3Hs https://blog.share.org/Article/mainframe-visibility-ibm-cham...
Re: The IBM mainframe: How it runs and why it survives
#107Earlier quoted context omitted.
> It persists in many places due to the deeply ingrained belief that, for one reason or another, it would be technically, practically, or economically impossible to migrate functionality off the mainframe. It is never technical or pratical reasons, always economic reasons. To use contemporary vocabulary, you "just" need to replicate a "multi tenant HA cloud environment" to migrate from a mainframe at great cost. > An…
>most of the business software that goes into said mainframe is in fact very simple and straightforward Yeah no. I worked on mainframe code for 15 years of the last 20 and can tell you that you’re wrong. Even reasonably simple business lines have cobbled together insane cobol, batch and cics screens that would make spaghetti blush. When you open up a 100,000 line batch program that’s just 1 of 30 cobol programs in th…
Because they keep the shit running. If you're a bank and responsible for trillions of dollars in assets and billions of dollars in daily transactions, the absolutely last thing you can afford is downtime or, even worse, data loss. You'll not just have to handle a ton of angry customers, but in the worst case attract regulatory attraction or getting dragged in front of Congress and the courts.
Here in Germany, Deutsche Bank is integrating 12 million accounts from Postbank to their own IT systems, and it has been an utter utter shitshow [1], attracting a lot of bad press and the banking regulator BaFin is also investigating [2].
[1] https://www.merkur.de/leben/geduldsprobe-fuer-postbank-kunde...
[2] https://www.sueddeutsche.de/wirtschaft/deutsche-bank-postban...
Re: The IBM mainframe: How it runs and why it survives
#108The reason mainframe persists is it's a pretty slick development and deployment environment. A lot things you might cobble together as dependencies - like maybe a database or a message queue, or observability facilities or even deployment strategies like hot-hot deployments - they're all just built in to the platform. That means they're trivial to consume and they're fully supported by one vendor. It's like the world…
Most of this Cloud technology we like to go all atwitter about is a retread or a redesign of software that's been on mainframes for thirty years. The old farts must laugh themselves silly looking at us acting like we discovered a large white object orbiting the earth.
E.g. how many variants of IRC have we had now? Usenet? VMs?
Re: The IBM mainframe: How it runs and why it survives
#109The reason mainframe persists is it's a pretty slick development and deployment environment. A lot things you might cobble together as dependencies - like maybe a database or a message queue, or observability facilities or even deployment strategies like hot-hot deployments - they're all just built in to the platform. That means they're trivial to consume and they're fully supported by one vendor. It's like the world…
Vertical integration of the business into one magic box is a perpetual dream of mine. Bonus points if I can yell at exactly one vendor if anything goes wrong.
Re: The IBM mainframe: How it runs and why it survives
#110The reason mainframe persists is it's a pretty slick development and deployment environment. A lot things you might cobble together as dependencies - like maybe a database or a message queue, or observability facilities or even deployment strategies like hot-hot deployments - they're all just built in to the platform. That means they're trivial to consume and they're fully supported by one vendor. It's like the world…
The Main Frame of yore was ... one of the 19 inch racks the computer was made out of (the main one, typically with the ALU and registers in it). And those racks were used because that was how phone systems were built (phone systems had a lot more repeated / regular structure than something like a computer, though of course everything has converged). The "frame" nomenclature came from the phone system too.
So "normal servers today" got the rack from the mainframe, the mainframe didn't adopt it because of how datacenters were built. All the familiar stuff (raised floors, chillers, backup power, fire suppression, controlled access doors and so on) come from the mainframe world.