IBM is doing a terrible job onboarding because they are all focused on offboarding.
This hardware is expensive and not as performant as any modern competitor. The software is arcane, confusing, and it is a pain for IBM themselves to keep supporting it. AS/400 is a costly legacy. AIX has no reason to be in a world that Linux and BSD exists - IBM owns Red Hat after all.
It was a cool technology. But it's definitely a thing of the past.
That all may be true for the actual implementation, but the idea of the ability to write an application with a built-in relational database that would be available to all my users relatively instantly is still a great idea, and the closest thing we get to that today is the web, but the web comes with it's own whole thing, least of which being a dev stack with so many moving parts by comparison.
On an AS400 you wouldn't even get a dev stack. Well, unless you wanted to pay IBM for 2 of them. Dev on production is the name of the game for most AS400 shops.
There were so many attempts to create something similar but modern that it isn't even funny. WinFS was first announced to be released in 1993, and the last I saw it was announced in Windows 8. This was one of the core ideas of BeOS, AFAIK they never really did give-up on it, just de-prioritized. The KDE people played with it at least twice...
It never works. There are insurmountable problems you notice once you try to design such a system. And yeah, AS/400 is an example of it not working too, as it was only usable as a hidden database layer and never survived contact with the users.
On the other hand, the obvious extension of the concept into development tools is a great idea that has been used to create novice-friendly toolsets all over. The tools always seem to "mature" away from it for some reason, and usually lose popularity on the process.
I'm not saying a full k8s stack, but consider mobile apps - you can't control when your user will update, if they do at all. So you either have to have a very rigid data model that makes a lot of translations and such on the backend, or a hook to check for updates and pester the user, or just ship late in pursuit of perfection. Plus now you get to deal with the entire Internet and cell networks and VPNs and bad actors.
> you can't control when your user will update, if they do at all
If you design your APIs to be versioned from the start, you don't need to be overly concerned with that. Also, if maintaining a deprecated API is too resource-consuming (either developers or API translation logic) you can always make it return a message informing the user the said API will cease to function on a given date (you need to make the app display that, even if not updated) and shut it down after that. Any mobile app should have a way to be placed in degraded functionality mode for a number of reasons, API deprecation being just one of them.
IBM still makes boatloads of money providing support and upgrade paths to it's legacy customers. They aren't _actively_ offboarding because it wouldn't make sense to lose that institutional market that they effectively own by the balls and that nobody will fight them for. It'd be hard to sell that tech to new customers though and it would also invite comparison to modern solutions, which would not please their current customers. It's like IBM is running a island prison / amusement park for rich old people. Just keep them happy and they'll keep paying.
My anecdata involves a foreign market. Maybe IBM USA is more keen on keeping this rolling, but in Japan we got strong pushback and were led to cloud solutions every time we discussed acquiring new hardware. They were very proactively trying to get us out of AS/400 and into their cloud platform.
Interesting, maybe they feel that they have a strong enough grip on their customers that they can move them away from proprietary hardware to higher-margins proprietary cloud solutions.
z is up to the minute in terms of clock speed, CPU process and such. They have a RAIM system which is like a RAID array for RAM which must cost something in latency but lets you replace failing RAM sticks when the machine is running. The rest of the industry will have something like that soon based on CXL.
Being up to the minute in terms of clock speed doesn't matter that much when, for example, DB2 on the AS/400/iSystem has a much higher latency and handle much less requests per second than an equivalent Xeon.
Replacing failing RAM sticks live are also something that, while quite cool and impressive, it happens to be quite pointless in today's world of clusters.
Current AS/400 is almost retrofuturistic in both its cool factor and disconnection from current actual needs.
This is one of the mainframe's key selling points. Not that I am implying z/VM is user friendly.
But instead of managing a fleet of x86 servers, switches, routers, storage boxes (you may need a few of those), all liable to fail without warning, you have an exquisitely built datacenter that fits in half-a-dozen 19" racks (counting 2 for storage) where redundancy, failover, and easy maintenance are built-in at the hardware level.
IBM still seems to invest a good chunk of money keeping up development of the POWER series.. the hardware improvements get shared by all the Linux/AIX/i software.
This hardware is expensive and not as performant as any modern competitor. The software is arcane, confusing, and it is a pain for IBM themselves to keep supporting it. AS/400 is a costly legacy. AIX has no reason to be in a world that Linux and BSD exists - IBM owns Red Hat after all.
It was a cool technology. But it's definitely a thing of the past.