Live data from Hacker News

The IBM mainframe: How it runs and why it survives

arstechnica.com

71–80 of 195 posts

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

#71
post #29

Earlier quoted context omitted.

I'm not sure how much water the multi tenant HA argument holds, these institutions are already doing that on AWS / Azure / k8s for the more modern apps. Rewriting all the old crusty COBOL code might be a different story.

Getting the same performance out of AWS as a local mainframe is neither trivial nor cheap for a lot of the workloads these systems are running.

Getting (and maintaining) a local mainframe in the first place is also not cheap though. I won't hazard a guess to which one might be easier to keep up and running, but at least in my bubble it would be 100x easier to hire more k8s admins than to hire qualified mainframe admins.

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

#72
post #39
post #29

Earlier quoted context omitted.

Getting the same performance out of AWS as a local mainframe is neither trivial nor cheap for a lot of the workloads these systems are running.

Getting stupefying amounts of I/O on AWS is as simple as turning a knob and getting out your credit card. The kind of throughput quoted in the article—48GB/s—is achievable on AWS for $250k/year, list price.

That is one channel of throughput, and a mainframe can have many channels, though.

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

#73
The mainframe exists because IBM and the devs respect the time and investments made by its customers.

There are efforts made to make sure code doesn't break and migrations are put in place.

Sadly only Microsoft and a few others share this attitude, and its likely why these companies and their products will be around forever.

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

#74
post #67

Earlier quoted context omitted.

The greatest hurdle for a project to be replaced is that if its works. I assure you that the users of IBM mainframes would be looking at at least a multi million dollar project to perform a decommission and if even approved it would be first on the chopping block to pause / eliminate the project.

You are correct. There was a time when companies ran projects to replace their mainframes. They all largely failed. The trend now is to integrate around the mainframe. Build new functionality on modern systems and leverage the mainframe where it makes sense. I worked at one company that is trying to replace their mainframe. The project is now in its second decade. The company has the burden of supporting the mainfram…

I've been on a couple of successful migration projects, both of which moved things to unices. One was motivated by the $5 million/yr costs to maintain the mainframe, which was replaced by a handful of lowest cost bidder unix boxes. The second was regulatory-agency-mandated cleanup after a financial fallout, and unlike the previous two or three times that company had tried and failed to consolidate their risk reporting onto a single system, this time it worked. Because it had to. The threat of an external regulator was sufficient to break down the previous barriers of balkanized system owners protecting their turf.

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

#75
post #51
post #39

Earlier quoted context omitted.

Getting stupefying amounts of I/O on AWS is as simple as turning a knob and getting out your credit card. The kind of throughput quoted in the article—48GB/s—is achievable on AWS for $250k/year, list price.

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

#76

I believe the real reason for its survivability is the fact that you can pull a tape from the seventies and those binaries will run without any modification. It's not only that you can easily recompile your COBOL from the '70s, the binary is still compatible. You've never been pushed to migrate to another technology. Imagine the effort and 'knowledge' included in those evolved programs. The banks don't even know, and…

This is both good and bad. You have to consider bugs a kind of feature like anything else. One of my coworkers showed me a bug report he'd opened 30 years prior that IBM still refused to fix because people depended on the broken behavior. So porting off the mainframe also means bringing along those quirks or rewriting to specs that provably don't regress performance and behavior. Writing or rewriting software is easy, but migrations despite how they first appear are not really "green field" development.

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

#77
post #8

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. Somehow the people in charge of these systems have managed to convince large enterprises of this for decades . And now we are in a situation where their long held beliefs have become true because nobody is around tha…

> 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 that run which is a mess of gotos, global mutable state and basically every single other generally frowned upon software practice we know about, you start to understand the issues.

Moving off of mainframe is practically impossible because of it. That other person being voted down is actually correct, nobody in the organization actually knows how any of it works.

When organizations try to transition away, what ends up happening is they get these insane promises of “5 years” from vendors (like IBM. Ask me how I know!), but then it takes 10 years to transition single systems.

Nothing is documented. So you have business people who have no clue how anything works providing high level work flows. But then there’s always 50 random edge cases or interactions they never considered cause the 40 year old code just does it.

IT contains most of the business knowledge, but the mainframe grey beards are… stubborn. The business hangs on to these people because they’re seen as insanely valuable, not realizing that the grey beards have actually been actively suppressing knowledge to only their hidden documents, and they’ve got 8 years till retirement and are going to make sure that their job exists at least until then by actively sabotaging efforts to change. But also, for some reason, the business manager love the saboteurs. It’s insane to watch.

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

#78
post #54

Earlier quoted context omitted.

You'll most likely find it in large companies that operated in the 60s or 70s that haven't switched to anything new, mostly because their core business runs on it. I know of two companies, and at least one still use it, had several summer jobs there. They make sheet metal rolls by flattening out train cart sized hunks of steel, and while the mainframe system didn't run the machines (operators and PLC handled that) it…

That could have been a mainframe, but I think factories are much more likely to be using AS/400 aka IBM i. That runs on regular IBM Power servers these days.

Can confirm. Work for a midsize manufacturer. Core of the business is on AS/400 and DB2.

Although a lot of new development is happening in C#/SQL/.NET and BLAZOR.

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

#79
I never worked on z/OS, but I did work on AS400 (Series I, or whatever it's called now).

I think the main things missing is how much IBM really brings to the table here.

> If one crashes or has to go down for maintenance, the other partitions are unaffected.

Effectively, IBM often does that for you. The machine detects an issue, and calls IBM, who sends someone out (in my day it was immediately), and they fix it. Then it's fixed and they leave and most of your staff has no idea they were there at all.

Plus, there's not enough that can be said about using a dedicated stack of hardware and software owned by one company. If there's an issue, it's IBM's. They are the ones who need to fix it. No trying to get HP vs Microsoft to agree to take the blame (which can take literal weeks). Just call IBM, and they take care of it. (In theory)

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

#80
post #67

Earlier quoted context omitted.

The greatest hurdle for a project to be replaced is that if its works. I assure you that the users of IBM mainframes would be looking at at least a multi million dollar project to perform a decommission and if even approved it would be first on the chopping block to pause / eliminate the project.

You are correct. There was a time when companies ran projects to replace their mainframes. They all largely failed. The trend now is to integrate around the mainframe. Build new functionality on modern systems and leverage the mainframe where it makes sense. I worked at one company that is trying to replace their mainframe. The project is now in its second decade. The company has the burden of supporting the mainfram…

I bet that the "modern" application, given its 20 years vintage, is probably a J2EE application running on whatever is the modern incarnation of IBM Websphere and it was written as a mind-boggling soup of EJB 2.x Entity and Session beans.
Post reply on HN