Live data from Hacker News

The IBM mainframe: How it runs and why it survives

arstechnica.com

101–110 of 195 posts

Re: The IBM mainframe: How it runs and why it survives

#101
post #85

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.

Can confirm. My old father who works on these mainframes laughs every time.

Re: The IBM mainframe: How it runs and why it survives

#102
post #77

Earlier 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…

> Ask me how I know!

how do you know?

Re: The IBM mainframe: How it runs and why it survives

#103
post #97
post #77

Earlier 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?

The estimate for carbon tax legislation was 700 hours and it took 1600 hours and didn’t work correctly for 9 months following.

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

#104
post #75
post #51

Earlier 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.

Well, the general approach over the past 30 years or so has just been to mostly go with generic x86 hardware which would get predictably faster year-over-year and software could be written pretty generically for those platforms. With performance growth slowing, one of the answers has been to have more heterogenous and special function hardware and the software people will just have to deal with it.

Re: The IBM mainframe: How it runs and why it survives

#106
post #59

Earlier 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...

Which part is untrue? That there isn't enough personnel or that it's a severely limiting career choice? Because what you're saying confirms the first one, and for the second one, not a lot of people dream of working on legacy stuff in a big organisation, and those are your only choices if you're a mainframe programmer. Say in the US, for mainframe work, there are what, 30 banks? 5 airlines? 20 insurance companies? Not a lot of choice, and it's doubtful they'll offer "perks" such as remote work.

Re: The IBM mainframe: How it runs and why it survives

#107
post #77

Earlier 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…

> But also, for some reason, the business manager love the saboteurs. It’s insane to watch.

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

#108
post #85

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.

I posit that most tech companies make money by poorly recreating old technologies for use by younger people ignorant of the old ones.

E.g. how many variants of IRC have we had now? Usenet? VMs?

Re: The IBM mainframe: How it runs and why it survives

#109

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…

I've always looked at IBM like an even more extreme version of Microsoft. I'd probably have us on their path if the cost and knowledge weren't a massive barrier to entry. I know IBM has some cloud thing for us baby startups, but I sure as hell can't figure out how to use it or if our customers are even aware of it.

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

#110

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…

> Going back to the hardware that everyone likes to focus on, it's less radically different from normal servers today than it was historically. The mainframe today is a 19 inch rack like any other.

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.

Post reply on HN