Just like the PC, they didn't realize it was important until it was too late. In my experience, mainframes are a superior way to develop and run every kind of software. The PC is a crippled, stupid stepchild by any reasonable comparison. Just the idea that you need to setup and manage 1,000 of them to come close to a small mainframe is ludicrous. Who needs the overhead and maintenance? Sure, you can swap machines and distribute loads between them, but who wants to? Yuck. It's a lot nicer to have that stuff handled automatically.

Also like the PC, IBM didn't realize that their boxes could be used for this new funky thing called the internet. Talk about blind-sighted. Their first web product was an abomination they inherited from their purchase of Lotus. It didn't work and produced unusable websites, boding poorly for IBM's entry into that market which was already taking off with Active Server Pages and XMLHTTP.

If IBM had loudly (and correctly) proclaimed that mainframes were the place to run web services, everyone and their mother would be running mainframes right now instead of Linux boxes. IBM's eventual realization of this led to their purchase of Red Hat!

> If IBM had loudly (and correctly) proclaimed that mainframes were the place to run web services, everyone and their mother would be running mainframes right now instead of Linux boxes.

No, they wouldn't. I could take one Linux box, get a domain name, and have a web server. I wouldn't be able to afford a mainframe, though. And if your alternative is renting a fraction of a mainframe, the answer is no. No, I will not trade a Linux box that I control for renting a piece of a mainframe that I don't control. Just no.

For enterprise is what I meant. Not for individuals.

Well, not just mainframes generally, but if they created AWS on mainframes and hosted them… that would have made it accessible for startups.

It was so simple internally, they could have ported those tools to a GUI. But GUI's and user interfaces are not something IBM has ever done well (other than command line ones).

The organisation is also in the way. Both in Ibm and for those teams using ibm. Very bureaucratic and like token ring over management kill. Good and have its niche. But murder by the liberal Ethernet.

I would argue neither has AWS yet…

The most logical place for a cloud service to develop inside IBM would have been IBM Global Services. IGS had a sort of proto-cloud set up in 1998-1999 (treated physical systems as cattle that could be remote wiped, virtualization would have been a logical next step) but sold off the organization building that to AT&T as part of the Global Network sale.

I wrote a horrible, hacky, CMS PIPES based gopher/http server for VM some time in 1993 that was used internally for various "non serious" things. A colleague and I designed a native HTTP server for MVS in 1995 and had started coding it when we were more or less reprimanded and told to defer to the then Network Services division which was porting something (I think CERN httpd, they had a bizarre fascination with CERN) to MVS.

It just wasn't in anyone's best interest to even experiment with web services on VM or MVS, let alone try to build a business out of it.

Cloud happened after I left, but the infrastructure to build or respond to the rise of AWS was never in place, sort of by design.

Sidenote: In VM, you could spawn a new machines with "physical" storage or drives (Nothing was physical on the mainframe; everything is faked just for you! Awesome.) by typing a single command at the command prompt! If you needed to fix a bug in some combination of operating system and IBM products, you could spawn that exact customer-replicating environment in about 2 lines of text.

Try that with Kubernetes!

LPAR makes LVM a joke.

It's sad to read about the dev headaches caused by today's poor virtualization environments. I distinctly remember that stuff was no work at all at IBM. It didn't interfere one bit with the actual work of coding on the products. In fact, we really never thought about setups or creating environments for testing or development.

In peer reviews, for example, it was standard to bring output from both the failing case and the working case as printed handouts. Those were easy to generate; just spin up two machines and fix one while you leave the other broken. They can share resources if you like so you don't have recreate everything. That is horribly messy today. Testing is so hard most people don't do it.

Also on simpler BSD's like OpenBSD, bioctl is dumb simple. Setting up a encrypted disk is a no effort task.

On firewalls, PF has a syntax simpler than most text adventure games.

Every time I get into the GNU world, well, I get better HW support sometimes, among a slight bit of performance, but, FFS, configuring a Linux firewall gives me nightmares everyday. Just compare NAT on Linux vs OpenBSD. Or TUN/TAP devices, where in OpenBSD it's just a matter of a SINGLE line at pf.conf and two hostname.if files to define the bridge and the tap device with a subnet. Done. Oh, and sysctl to set IP forwarding, but that was the easiest task on any OS.

In a sense, a parallel sysplex with remote hosts and storage is a very sophisticated private cloud environment that'll run your CICS transactions a lot like you do with AWS Lambda.