> A handful of grumpy old gits know that if you pick the right languages, and the right tools, you can build something to replace this 2nd level system in the same types of tools as the first level system, and that you don’t need all the fancy scaling infrastructure because one modern box can support a million concurrent users no problem, and a few such boxes can support tens of hundreds of millions of them, all in something in the corner of one room, with an uptime of decades and no need for any cloud.
I suppose I am a grumpy old git, then, although I did not think of myself that way until recently. In the past decade or two, I've seen computer science lose its collective appreciation of the staggering potential of hardware. This has steadily resulted in software being built with tremendously over-engineered, hyper-complicated, cloud-first architectures that barely match the throughput of a single box running a high-performance platform (and for the record, "high performance" can still be relatively ergonomic via Java, C#, Rust, and so on).
The scale of hardware, clock cycles, bits per second of bandwidth, etc., being squandered on modern cloud-first highly complicated architectures boggles the mind.
I fear there is no strength behind any pendulum swing back to architectural simplicity, appreciation of the available capacity of hardware and how to use it, and local-first.
> I fear there is no strength behind any pendulum swing back to architectural simplicity, appreciation of the available capacity of hardware and how to use it, and local-first.
I'm pretty sure, the ecological devastation we are living will raze these things. If we are lucky we can salvage a bit. And the whole industry of the last 20years isn't worth saving.
> I fear there is no strength behind any pendulum swing back to architectural simplicity, appreciation of the available capacity of hardware and how to use it, and local-first.
The reason why there is no strength is that "cloud" seems to be the only way to monetize software.
I think that's changing. You're seeing more companies investing more in custom silicon. Like Microsoft, Amazon, and Google all make custom silicon to support their cloud efforts. That's expected to increase over time. Apple has shown that if you don't settle for BOG standard hardware you get better than BOG standard performance.
>, and that you don’t need all the fancy scaling infrastructure because one modern box [mainframe] can support a million concurrent users no problem, and a few such boxes can support tens of hundreds of millions of them, all in something in the corner of one room, with an uptime of decades and no need for any cloud. But it’s hard to do it that way,
The author proposes that "mainframes-are-superior" by vague generalizations and no performance data.
As a case study, consider that the Sabre travel reservations was the first IBM mainframe commercial customer since 1960. With 6 decades of experience with IBM 360 and Z upgrades, they'd know more about running mission-critical performance workloads on mainframes than just about anyone.
To think of the opposite case from Sabre, let's consider a new YC startup today with no legacy IT systems. Thinking from first principles (i.e. raw math of cpu & io performance & costs on an Excel spreadsheet), what situation makes sense to build the solution on an a new IBM z16 mainframe instead of cloud?
If one is an old bank already running an older IBM z14 or z15 mainframe and wants the next iteration of performance improvements, a z16 upgrade is the simplest so probably makes the most financial sense. But without a "legacy IT" constraint, what's the compelling spreadsheet model for a YC company to choose a mainframe?
> raw math of cpu & io performance & costs on an Excel spreadsheet
But that's not the raw math; the raw math is "total OpEx", and OpEx for these large systems is increasingly dominated not by the systems themselves, but rather by development-talent acquisition costs, and operational-maintenance talent labor costs.
Even Sabre's choice wasn't "upgrade to z16 vs. move to IaaS"; it was "hire people to replace churned devs+ops to write the next feature of the system: people with z/OS experience, or people with IaaS experience?"
"But without a "legacy IT" constraint, what's the compelling spreadsheet model for a YC company to choose a mainframe?"
The most compelling reasons for the mainframe, based on its intrinsic values, are 'RAS' (reliability, availability, serviceability). However, those virtues come with a very high price tag. So far the most part, I cannot imagine any startup business choosing one (UNLESS system downtime will kill the business).
Plus, you can squeeze out those same RAS factors from a cluster of commodity x86 boxen, at the software level, if your devs are willing to learn a little Erlang.
Migrating away from mainframes can also be just because of talent availability but also lock in.
Where I work we have processes that would make perfect sense chucking jobs at a mainframe (if we implement our language on it...), but IBM have no competition so it's super risky.
> Unisys later switched to running on commodity x86 servers
It runs the same OS on an emulation layer. Not sure they do it, but you can get zero downtime out of multiple x86 boxes with a number of interesting tricks while pretending you are on a single CPU
This actually got me fairly curious as to what the big difference is between mainframes and regular ol' micros. I don't think I ever used a proper mainframe, and I honestly wanted to know more. The author keeps building up to this massively different, otherworldly system, and then just finishes without ever answering.
I did feel some contempt towards certain developers (who dare call themselves software engineers) and there was definitely an "old man yelling at cloud" undercurrent. If only I could learn something of merit, that would have been worth it.
So I guess it's up to us plebs to go and see what makes mainframes so different. How the "weird" custom architectures work. What's it like to work on one and write code for it.
> The author keeps building up to this massively different, otherworldly system, and then just finishes without ever answering.
Yes, it's a weak article.
So, what do mainframes have that microcomputers don't?
- Much more internal checking.
Everything has parity or ECC. CPUs have internal checking. There are interrupts for "CPU made a mistake", and OSs which can take corrective action.
- Channels.
Mainframes have channel controllers. These connect to devices on one end, and the main CPUs and memory on the other. They work in a standardized way, independent of the device. The channel controllers control what data goes to and from the devices. Sometimes they even control what a program can say to a device, so that an application can be given direct device access with access restrictions. This would, for example, let a database talk to a disk partition without going through the OS, but limit it to that partition. The channel controllers determine where peripherals put data in memory. Mainframes have specific I/O instructions for talking to the channel controllers. Drivers in user space have been around since the 1960s.
Minicomputers and microcomputers, on the other hand, once had peripherals directly connected to the memory bus. Programs talked to peripherals by storing and loading values into "device registers". There were no specific I/O instructions built into the CPU.
Some devices accessed memory themselves, called "direct memory access", or DMA. They could write anywhere in memory, a security and reliability problem.
Microcomputer CPUs haven't worked that way for decades. Not since the era of ISA peripherals. But they still pretend to. Programs use store instructions to store into what appears to the CPU is a memory block. But that's really going to what's called the "southbridge", which is logic that sends commands to devices. Those devices offer an interface which appears like memory, but is really piping a command to logic in the device. On the memory access side, the program stores into "device registers" which tell the "northbridge" to set up data access between devices and memory. Sometimes today there's a memory management unit between peripherals and main memory, to control where they can store.
The end result is something more complicated than a mainframe channel, but without the architectural advantages of isolating the devices from the CPU. Attempts have been made to fix this. Intel has tried various types of I/O controllers. But the architecture of Unix/Linux isn't channel-oriented, so it just adds a layer of indirection that makes drivers more difficult.
(Then came GPUs, which started as peripheral devices and gradually took over, but that's a whole other subject.)
- Virtual machine architecture
The first computer that could virtualize itself was the IBM System 360/67, in the 1960s. This worked well enough that all the System/370 machines had virtual machine capability. Unlike the mess in x86 world, the virtual machine and the real machine look very similar. Similar enough that you can load an OS intended for raw hardware into a virtual machine. This even stacks; you can load another copy of the OS inside a VM of the first OS. I've heard of someone layering this 10 deep. The way x86 machines do virtualization required adding a special layer in hardware underneath the main layer, although, over time, it's become more general in x86 land. Arm AArch64 considered virtualization from the start, and may be saner.
> So, what do mainframes have that microcomputers don't?
Some high-end UNIX servers have historically had many of the features you mention – yet generally not considered "mainframes". Conversely, low-end IBM mainframes (such as the 43xx series) often lacked some of those reliability features – and I'm not sure if all the contemporary non-IBM mainframe platforms have them (especially the ones which are nowadays emulated).
I think the real definition of "mainframe" is historical rather than being in terms of any particular technological features. Primarily it refers to high-end commercial-focused (i.e. not supercomputer) computing platforms from before 1980, and their later compatible descendants (which weren't necessarily all that high-end).
(That said, "mainframe" and "supercomputer" are historically overlapping categories, since some 1980s supercomputers such as the Hitachi S-3800 were S/370-based and hence arguably belong to both categories; similar remarks could be made about the IBM 3838, or NEC SX-1 and SX-2.)
> But the architecture of Unix/Linux isn't channel-oriented
Unix and Linux run on IBM mainframes and use IBM mainframe channels for IO. z/Linux uses IBM mainframe channels. So did AIX/370, AIX/ESA, VM/IX, IX/370, and Amdahl UTS. And, z/OS is officially speaking Unix too (it is certified as such by The Open Group)
Channels are an implementation detail which usually only OS device drivers need to concern themselves with. (Historically some applications interacted with channels directly – e.g. EXCP on MVS – but IBM strongly discourages that approach nowadays, they'll recommend you use VSAM or DB2 instead, in which all those low-level details are hidden from the application.)
The maybe most distinguishing feature of a "mainframe" is intelligent I/O channels, which offloads a lot of what would otherwise be CPU work. And those I/O channels is why the PDP-10 was called a "mainframe" while the rest of the PDP series (without I/O channels) were called "minicomputers".
There's more, but it depends on the system - some can do maintenance on parts of the system while still operating.
They also have it with disks local and remote. The idea is that the CPU is running user code 100% of the time and that it doesn’t need to wait for anything.
I think the real reason why it works for mainframes is that their operating system is so primitive, so it’s easy to cross layers - because there are so few of them. z/OS is closer to MS-DOS than to Unix in that regard.
> some can do maintenance on parts of the system while still operating.
That's not that rare these days. Basically any server will allow hot-plugging hard drives, with some configurations network cards and by now a lot of laptops can even hot-plug GPUs via Thunderbolt.
I remember some big iron could do it with processors and memory as well. IIRC, you can no longer remove CPUs with IBMs, but replacing memory is relatively simple.
Hot-plugging hard drives is a bare minimum. There are many other points of failure and a failure of any of the following WILL result in downtime while the component is replaced: disk controller, CPU, memory, NIC. Having dual NICs and dual processors helps, but it's still a far cry from 100% availability.
If you want to quickly get a feel for traditional IBM mainframe software, you can do that easily enough. Download Hercules mainframe emulator [0] and then you can fire up MVS 3.8 [1] or VM/370 [2]. Be aware that the community has made significant improvements on these old open source software systems.
Hi. I wrote the piece. Thanks for taking the time to read it.
I wasn't aiming or trying to give a worked example of the differences, though.
That's in the link that inspired the comment. Didn't you look at that? It's exactly what you ask, with discussions of filesystems, CLI, even C code examples. It would have been redundant to try to duplicate that. It's why I recommended it. I still do. You should read it, because it sounds like what you want to me.
Cloud services and hyperscale data centers are arguably modern mainframe-class systems. If you look at them from the perspective of the provider, they have a lot of mainframe type features that distinguish them from micros or supercomputers.
In the 70s, VM/CMS dominated the time-sharing landscape, and everything old is new again.
Just no. They are very large herds of cattle systems, which act like as a big pet system, because it tolerates small blows.
A mainframe is a single pet, which can live undisturbed even with moderate size blows, and can host a sizable herd of cattle systems without even noticing on the load monitor.
yup. error detection in the CPU (Alu, Decoder, etc) traps into the hypervisor which fires up a spare core, transfers the registers over to it and calls the technician.
technician calls you to tell you "your machine needs maintenance"
and at application level there was a short "mouse hang" latency for this hardware failure.
and of course that works cross-site, too, hot moving running software across data centres at the hypervisor level, because you want one data centre downtown, one at the airport.
but it's not just for finance.
some mainframe customers have virtualized thousands of "your personal domain and web server running php/perl/nodejs" on a single physical machine which shares a r/o mounted /usr, in ram, transparently.
customer X needs more ram? click click life assign more ram. needs more cpu? activate another core. the Linux virtualization Features to support hit cpu and ram swap were driven by the mainframe guys from IBM, years ago.
What would prevent, in your opinion, to make some changes to current commodity hardware architectures (say, x64, arm...) to allow for mainframe-like scalability and reliability ?
As per the article, how is the jitted/interpreted world of languages so bad ?
on a more serious note yagni: for most workloads you simply don't need the dependability and Xeon has caught up sufficiently for most workloads.
however if your business depends on less than 5 minutes of unplanned downtime per year you need stacks designed for faul operational subsystems, i.e. subsystems which don't just detect faults and halt, but which gracefully handle many faults with a short degradation but no failure.
and that's not only hard to master it's also plastered with IBM patents.
wrt the jit/interpreted world my personal take is that silicon vendors are very happy about it. very few organisations feel the pain to an extent they innovate things like golang... and once they are in the business of selling compute power (as cloud service provider), there goes their motivation to create a sexy cobol.
ECC bring the norm and better error handling all around. OSes that better handle memory and uptime. Possibly something like a user session being accessible from allowed terminals and applications that call for that. Think hotel front desk staff or anyone public facing who move from desk to desk.
There's far more to reliability than ECC. What if a processor/CPU goes bad in an x86 server while running? You have to take the server down, replace it, and bring it back up. IBM mainframes allow for processor replacements while it's running. I think it's the same with memory. IIRC, in the mainframe world IBM has processor and RAM packaged together as a 'book' and it may be the book that can be hot swapped. Hopefully someone more knowledgable can clarify.
A mainframe reminds me more of a cluster of specialised machines networked over ridiculously fast interconnects and purpose-specific networks that host those specialised machines.
Some functionality of those specialised machines is exposed to user programs that can delegate some processing to these smart peripherals, offloading things like allocating blocks in the filesystem and letting the boxes that run your used code focus on running it without ever being disturbed with servicing network or disk interrupts.
I'd say cost (of research, implementation and resulting product
).
The additional hardware both in silicon and on PCB is massive to enable these kinds of reliability numbers. I played with some higher end HP servers back in the day, which allowed hot-swapping RAM carriers to maximize uptime. The construction on mechanical, electrical and software was much more sophisticated to enable these features. Which made the systems bigger, somewhat noisier and harder to maintain in a sense.
When everybody is moving towards more cattle-like systems, and the behemoths like HPC doesn't care about reliability in the worker nodes (we just re-schedule the job, no biggie), that kind of reliability is not wanted by the people, in most sectors, and this low demand doesn't make the capabilities worthy to pursue.
Also, there are system dynamics which affect operations profoundly. Your normal server boots in 5 minutes tops from power to "all services are ready to serve". Your run off the mill SMP server needs 15 minutes. A mainframe is never expected to be shut down, and if it's ever turned off, it's at least an hour required to spin that thing back up.
We're talking about machines which have small "guns" inside to physically sever power lines in an emergency (sorry I can't find the story I've read about moving a datacenter hence turning of the IBM mainframes, however a related reference can be found at [0]).
The JIT/Interpreted languages of the day were really bad. Java was heavy, other languages were slow. Today's JIT/Interpreted languages are fast enough, because the VMs running these have been optimized heavily, and the processors allows these VMs to run at much faster speeds because of available instructions, available memory and system interconnect speed at every level and interface. So the evolution of JIT and interpreted languages is a matter of chicken and egg. Hardware enabled both faster speeds and technology to write better VMs and optimize them further.
That’s more of a training / staffing issue than a tech stack issue. I’ve seen similar outages at my clients in distributed systems. A lot of mainframe staff has been outsourced / offshored and those providers suffer constant turnover because the money and job prospects in distributed systems is generally better.
Mainframe jobs pay well at the very apex of skills, but if you’re coming up through the ranks in an outsource provider you’re a cost not profit center. The compensation package and work life balance are good if you are with a company that keeps everyone in house, trains in house, have a deep bench of expertise who maintain the systems in an orderly fashion, and have a continuous succession plan for staff. Super low drama, and they keep the financial lights on in the house by processing the bulk of profit-generators’ needs. These tend to be in places like stodgy COBOL shops the Cool Kids would rather gnaw their feet off to avoid, though.
The part many people miss when comparing mainframes and distributed is you get all that mainframe magic with the application programmers accommodating the architecture little if at all. But your system programmers (system admins in Linux) have to be top tier.
You can accomplish most if not all of that same magic in distributed architectures with parallelizable workloads. But your application and devops staff have to be top tier.
> That’s more of a training / staffing issue than a tech stack issue.
I mean sure, but the same could be said for distributed systems. What breeds reliability is qualified personnel working on a system that they understand. Slapping an IBM logo on the front doesn't make something more reliable, and stacking proprietary technology that "transparently" moves subsystems between datacenters only increases the training burden.
Mainframes became a victim of their own moat. While proprietary .magic. can hold people in, those very same technologies also keep new people out.
> some mainframe customers have virtualized thousands of "your personal domain and web server running php/perl/nodejs" on a single physical machine which shares a r/o mounted /usr, in ram, transparently.
IBM was paying them to do it. The problem is you’re running in a separate set of processors… it’s almost like a blade chassis at this point. The cost structure didn’t work as if you’re doing anything significant you’re going to end up licensing more CPU time (yes, you need to buy access to the stuff you bought), and it cheaper to buy x86 and run Linux OR just rent VMs from Amazon.
I had to do a POC of this for an IBM app in 2008-9, as it was seen as a way to save on IBM software licensing. I killed the notion after spending 6 months getting stuff to work (ie the IBM boys and inwere the first idiots to try) when i borrowed from surplus PCs awaiting shredding and replicated the entire environment on 6 circa 2005 pentium whatever desktops (which I did during the week between Christmas and New Years). My little lab outperformed the mainframe by a factor of 5 for the task.
If these solutions were sold commercially, there must have been some German compliance requirement that led people to do it. Nobody would ever do this without getting directly compensated for “choosing” to do so.
what works financially is providing a fleet of simple similar independent machines.
think "your personal wordpress instance w/ own email and ftp server", centrally maintained, identical baseline but individual content.
to this day Linux KVM does not enable multi tenancy. with z/VM you can provide that, and you still have the shared /usr in physically shared ram in z/vm.
the physical CPUs are also virtualized and shared, each "full own wordpress server" only needs slivers of that cpu pool.
it was done and it qorkwd. and it was profitable for both the hosters and IBM.
Yes - that was very interesting one of the drivers for what I was working on was that the z/VM segmentation would allow for partitioning of workloads to avoid over-licensing and address some security needs.
The tough part was if you didn’t have that perfect scaling opportunity, things fell down fast, and the marginal cost for more resources was way too much. IBM tried to oversell it.
> but it's not just for finance. some mainframe customers have virtualized thousands of "your personal domain and web server running php/perl/nodejs
To be fair, shared hosting providers did this on x86 server machines on a scale of 100s of customers in the 90s, and I'm sure a modern revival on 2022 could do 1000s also
Sure, but they way we did that back in the 90’s was very different, and carried a much lower overhead than LPARs in the IBM mainframe world or any hypervisor or container used today — shared hosting “virtualization” in the 90’s was little more than chroot jails, and frequently not even that.
I think you're confusing LPARS with guests under z/VM. A mainframe LPAR is a coarse-grained (relatively speaking) partitioning of the system. LPARS are created and managed by a Hardware Management Console (HMC), and run on PR/SM [0]. No one creates mainframe LPARS to run a VPS. Those would simply be a guest under z/VM. Realistically speaking, z/VM would be running in an LPAR (less than the whole of the mainframe resources) and then within z/VM's LPAR, z/VM hypervisor allows all of its guests to run concurrently.
We have a 10 machine Proxmox cluster at the office, and no. It doesn’t lend itself to such capacities.
Maybe we over-provision systems, and can fit that number of VMs, but what will be the performance?
You can use a proper SMP machine with 16 sockets, but you are already at half mainframe price and journey-wise, and you’ll be wasting the machine’s capabilities.
I'm not sure if an IBM i system would really qualify this way, it's mini software running on downscaled mainframe hardware.
IBM i is probably the last mini out there, it will feel completely alien to someone coming from the microcomputer world (say, *nix and Windows, x86 and ARM).
IBM i is very interesting: the last mainstream single-level store system. This is a concept I've both talked and written about in recent years -- examples here on HN:
Saying that, I've done very very little work on the system. One job ever, really, 20Y ago.
But IBM i is OS/400, yes, a minicomputer OS, yes -- but running on IBM P series, i.e. a POWER server, i.e. a modern RS/6000. It's a RISC workstation. Not even slightly mainframe-like.
Other minicomputer OSes survive, notably VMS, now on x86-64.
So, yes, mini OSes survive, sure, but not really any mini hardware. Arguably as minicomputers died out they evolved into workstations, and those have now died out, too. 99.99% of the workstation market is basically high-end PCs now, if we count modern Macs as sort of honourary PCs. (Arm Macs are in some ways more like desktop/laptop-shaped iPads, really.)
All I'd say is this: "midrange" is an IBM sales concept, and I don't think it was ever really used much outside IBM.
"Minicomputer" is a generally-accepted industry term, or at least, it was once. Minicomputers were not specific to IBM, just as mainframes weren't either.
I think those definitions are somewhat complicated, because micro-computer architectures have gradually adopted features (perhaps in reduced form) from their mini-computer and mainframe counterparts.
So, mainframes have channel controllers, and micro-computers don't. But a modern micro-computer Ethernet driver might run some software on the NIC. It's not really a channel and yet the architectural distinction is blurred.
The distinctions made more sense in the 80's, when the lines were clearer.
But I think the point is valid: the micro-computer architecture has taken over the industry, and some things of value have been lost.
Similarly, the "bus" of a micro-computer started out as a pretty simple thing: parallel, 8 bits of data, 16 bits of address, with memory-mapped or I/O-mapped fixed-function peripherals managed by the (single) CPU. Memory and I/O devices on the same bus.
But the modern PCIe "bus" is really more of a packet-switched network. Memory is now separate (although, see CXL). Devices on that network can talk directly to each other, or to the CPU. In some ways, this is closer to a mainframe architecture.
It absolutely is. IBM started to bring mainframe features to the PC architecture with its PS2 line. The PS2 microchannel architecture (MCA), in particular, was inspired by the 360 and became itself the inspiration for the PCI bus.
Mainframes: the first style of computer. Primarily designed as a batch-oriented system, meaning that they are not directly interactive. Jobs are queued up, run without interaction, results stored, and then the next job processed. Later models added interactivity as a secondary feature, usually like most mainframe I/O handled by intelligent peripherals which in effect are networked to the main processors. So, the terminal, on its own, shows a form and then handles all user input as the user completes the form, without communicating with the host at all. Then, when the user signals that the form is complete, the entire contents, maybe many pages, are sent as a single message to the host.
Separate processors in storage, in terminals, in networking controllers, in printers, in everything. Typically the machine cannot actually drive any output or input directly (e.g. mouse movements, or keystrokes, or anything): peripherals do that, collect and encode the results, and send them over a network. So as someone else commented, a mainframe isn't really a computer, it's a whole cluster of closely-coupled computers, many with dedicated functionality. Quite possibly all implemented with different architectures, instruction sets, programming languages, bit widths, everything.
Here's an article I wrote about a decade back about how IBM added the new facility of "time sharing" -- i.e. multiple users on terminals, all interacting with the host at the same time -- by developing the first hypervisor and running 1 OS per user in VMs, because the IBM OSes of the time simply could not handle concepts like "terminal sessions".
Minicomputer: the 2nd main style of computer. Smaller, cheaper, so affordable for a company department to own one, while mainframes were and are mostly leased to whole corporations. Typically 1 CPU in early ones, implemented as a whole card cage full of multiple boards: maybe a few boards with registers, one with an adder, etc. The "CPU" is a cabinet with thousands of chips in it.
Hallmarks: large size; inherently multitasking, so that multiple users can share the machine, accessing it via dumb terminals on serial lines. User presses a key, the keystroke is sent over the wire, the host displays it. Little to no networking. One processor, maybe several disk or tape drives, also dumb and controlled by the CPU. No display on the host. No keyboard or other user input on the host. All interaction is via terminals. But because they were multiuser, even the early primitive ones had fairly smart OSes which could handle multiple user accounts and so on.
Gradually acquired networking and so on, but later.
In some classic designs, like some DEC PDPs, adding new hardware actually adds new instructions to the processor's instruction set.
Wildly variable and diverse architectures. Word lengths of 8 bit, 9 bit, 12 bit, 18 bit, 24 bit, 32 bit, 36 bit and others. Manufacturers often had multiple incompatible ranges and maybe several different OSes per model range, depending on the task wanted, so offering dozens of totally different and incompatible OSes across half a dozen models.
Microcomputer: the simplest category. The entire processor is implemented on a single silicon chip, a microprocessor. Early machines very small and simple, driven by 1 terminal with 1 user. No multitasking, no file or other resource sharing, no networking, no communications except typically 1 terminal and maybe a printer. Instead of 1 computer per department, 1 computer per person. Facilities added by standardised expansion cards.
This is the era of standardisation and commoditisation. Due largely to microcomputers, things like the size of bytes, their encoding and so on were fixed. 8 bits to a byte, ASCII coding, etc.
Gradually grew larger: 16-bit, then 32-bit, etc. In the early '80s gained onboard ROM typically with a BASIC interpreter, on-board graphics and later sound. Mid-'80s, went to 16-bit with multicolour graphics (256+ colours), stereo sound. Lots of incompatible designs, but usually 1 OS per company, used for everything. All single-user boxes.
These outperformed most minis and minis died out. Some minis gained a hi-res graphical display and turned into single-user deskside "workstations", keeping their multitasking OS, usually a UNIX by this point. Prices remained at an order of magnitude more than PCs, and processors were proprietary, closely-guarded secrets, and sometimes still implemented across multiple discrete chips. Gradually these got integrated into single chip devices but they usually weren't very performance competitive and got displaced by RISC processors, built to run compiled C quickly.
In the '90s, generalising wildly, networking became common, and 32-bit designs became affordable. Most of the 16-bit machines died out and the industry standardised on MS Windows and classic MacOS. As internet connections became common in the late '90s, multitasking and a GUI were expected along with multimedia support.
Apple bought NeXT, abandoned its proprietary OS and switched to a UNIX.
Microsoft headhunted DEC's team from the cancelled MICA project, merged it with the Portable OS/2 project, and got them to finish OS/2 NT, later Windows NT, on the N-Ten CPU, the Intel i860, a RISC chip, then on MIPS, and later on x86-32 and other CPUs. This was the first credible commercial microcomputer OS that could be both a client and a server, and ultimately killed off all the proprietary dedicated-server OSes, of which the biggest was Novell Netware.
That is a vastly overlong answer but it's late and I'm just braindumping.
Mainframe: big tightly-clustered bunch of smart devices, flying in close formation. Primary role, batch driven computing, non-interactive; interactivity bolted on later.
Mini: departmental shared computer with dumb terminals and dumb peripherals, interactive and multitasking from the start. Most text-only, with interactive command-line interfaces -- "shells" -- and multiprogramming or multitasking OSes. Few had batch capabilities; no graphics, no direct I/O, maybe rare graphical terminals for niche uses. Origins of the systems that inspired CP/M, MS-DOS, VMS, UNIX, and NT.
Micro: single-chip CPU, single-user machines, often with graphics and sound early on. Later gained GUIs, then later than that networking, and evolved to be servers as well.
If the machine can control and be controlled by a screen and keyboard plugged into the CPU, it's a micro. If its CPU family has always been a single chip from the start, it's a micro. If it boots into some kind of firmware OS loader, it's probably a micro. The lines between micros and UNIX workstations are a bit blurred.
I'm not sure this is helping any more. I'll shut up.
If you squint a bit, you can view Web-1.0-era UIs as being a bit like a 3270: the terminal downloads the template, the user fills out the fields, and hits the submit button. That creates a HTTP POST, which is kinda like a CICS transaction.
This enables the central CPU running the application server to ignore all the terminal I/O issues, and just deal with a set of transactions implementing the application logic. If the load-balancer and HTTP server are separate machines, then at a high-level boxes-and-lines level, it's not a long way from a mainframe application architecture (at the front end, anyway).
But this isn't really accurate, and it's become less superficially similar with more recent web trends where the REST layer isn't a hard boundary, and pre-rendering and so on have muddied the model again.
Yes, agreed, and you're not the first I have heard make that comparison.
I think it (as in, late-era Web 1.0 as opposed to Web 2, meaning Javascript everywhere) bears deeper examination.
By which I mean, I think the world and the industry got distracted by the shiny, as it always does, and is so into Javascript and building clever stuff in it, that nobody has taken the time to stop and ask: hey, was Javascript a bad idea?
Which leads on to...
Could we experimentally stop using it and be better off? Could we go back a step, improve upon Web 1, without embedded scripting languages of any kind, and maybe produce a better web based on that?
This need not mean stopping anyone doing what they're doing. It merely means someone exploring alternatives on the side.
I've been wondering whether there's any way to encourage this.
E.g. by crowdsourcing a prize for an annual competition for the best JS-less website or something.
Use all the latest shiny in HTML 5, CSS as well if that's what people want -- the last time I designed a web page, CSS hadn't been invented yet, so I know nothing about it -- but no PHP, no Javascript, no scripting at all. Flat static web pages, but using the power of modern computers and browsers to make 'em look nice and work well.
But rather than arbitrary size limits, I am thinking of technological limits.
An unanswered question for me is the server side: is serving it from some whizzy dynamic engine that assembles the pages on the fly OK? Or is that a whole different target?
Should it be low-tech, i.e. static content only?
Or should it be high-tech, but only on the server?
I tried to stick to documented history only, so I am not sure what there is to disagree with TBH, but, er, OK. :-)
The thing is that minicomputers sort of got squeezed out by history, and the final stages of that were as messy as the metaphor hints.
So on the one hand, micros expanded to occupy the niche, and some micros can actually run minicomputer OSes, so does that mean that those micros became minis?
This becomes a philosophical question. For comparison some people like to say "dinosaurs never died out, because birds are dinosaurs!" Well, kinda, yes. But birds are one small type of dino. There are no 4-legged birds, no birds with working forelimbs other than wings: no arms, or hands, or gripping claws, or walking forelimbs; no birds with teeth; no truly herbivorous birds; and so on. One small branch of the dino family survived, and prospered and thrived and is doing great, but it doesn't represent the profusion of types of dinosaur there were.
Well, yes, late minicomputers had networking, could drive fancy graphical terminals and so display graphics, and some were powered by CPUs that had been shrunk onto a single chip... but they evolved from a different line of devices and convergent evolution gave them some microcomputer-like aspects.
There were also PC-type devices like the Jarogate Sprite, with an x86 chip, a machine that ran Concurrent CP/M only, had a floppy drive and a hard disk, but could only be accessed over dumb terminals. It didn't have or support a display. You couldn't connect a keyboard to it. It was a small minicomputer built using PC tech.
Another example is Alpha Micro. Obscure now, so you've probably never heard of them. Here's the best site about them:
Alpha Micro made Motorola 680x0-powered computers, with a proprietary OS that was in effect a 3rd party clone of DEC mini OSes, especially TOPS-10 and RSTS/E. A notable feature was that the only removable media were tapes, but not computer tapes: VHS videocassettes. That's how software and updates were distributed: data, on a videocassette.
A small host machine with no keyboard, no display, no way to add them; a host that could only talk to terminals; a proprietary multiuser/multitasking OS and most apps written in compiled BASIC.
These are all attributes of a minicomputer. But it used microcomputer parts and processors.
Alpha Micro, Jarogate Sprite -- which is it: a mini or a micro?
Well, kinda, both...
A single-user minicomputer with a big hi-res graphics display, a local keyboard and mouse (probably attached over serial ports with a weird plug, because it evolved from a mini that only could talk to terminals)... available with a choice of CPUs, including proprietary, or 386s and 486s, or Motorola 680x0, but mostly fancy expensive RISC chips... but it acts like a mini, runs a mini-derived OS (usually UNIX)... and like a mini, it costs as much as a small house...
OTOH it's single user. Is that a mini or a workstation? Is a workstation a kind of microcomputer?
It's hard to say. Is a bird a dinosaur? It's hard to say.
But the key thing is that all the workstations are gone now. The last vestiges were late Sun workstations, most with Intel chips. All gone. IBM still makes POWER machines but not workstations. HP stopped when Itanium flopped.
Some of these companies still make server boxes with their RISC chips that evolved from minicomputer-type things. A server isn't a workstation, though. Workstations have big graphics displays, and late ones had fancy 3D cards to drive them, cards that cost as much as a small PC network on its own, and had more memory than that whole LAN put together.
Servers have cheap crappy PC-derived graphics chips that only show the firmware screen. You drive them over the network, possibly by some bodged-on "lights out management" card which pretends to be a serial terminal, captures output from the display, and then sends it over the network.
Ugly bodged hack of a tech, designed for PC servers that are at heart microcomputers with a frame buffer and a local keyboard, and that's the only way to access the firmware so the network-only server needs to fake and capture and redirect it.
Which makes that commodity tech, so you can bolt it onto proprietary servers that evolved from RISC workstations which evolved from minicomputers... so you use the ugly PC kludge in place of a device which, deep down in its firmware somewhere, actually would happily talk to a dumb serial terminal and doesn't need the ugly PC-originated hack.
The lines are blurred. It's not clear any more which is which.
IBM P series servers are POWER machines that natively run AIX. The POWER CPU line evolved from the RIOS/ROMP processor in the IBM RT-PC.
That's a deskside minicomputer with a processor complex made from 5 or 6 separate chips. But IBM marketed it as a workstation-cum-PC-replacement, and the Wikipedia editors even call its chip a microprocessor, which it definitely wasn't.
IBM i (iSeries, AS/400s) are considered "midrange" computers. Indeed the author is a bit wrong on this considering IBM introduced the AS/400 specifically as a "midrange system".
I've heard a few folks use this term disparagingly lately, and I just want to point out that the spirit of an MVP isn't that you do the bare minimum required to huck your product to an unsuspecting customer. The point of an MVP is that every milestone you deliver something that's actually useful and functional in some way, end-to-end. The alternative to an MVP is a junk mock-up with all of the technical debt swept under the rug and the devs whistling and looking the other way when questions start coming out.
As someone who’s worked deeply on mainframe and minicomputer systems and then worked even more deeply in the cloud, there is really no point to mainframes anymore unless you are doing a realtime application, which in most cases is unnecessary.
The only value proposition I see is realtime redundancies, which are physically impossible with geographically distributed systems, but par for the course on mainframes. For most non-realtime applications, though, you can achieve same or better uptime for cheaper and with better flexibility building in the cloud.
If that is true then that is enough of a selling point. Cloud providers with 5 9's have one or two outages a year. If you need the uptime for systems that can't have one outage in a decade, is there a competing solution?
Originally from Tandem, then bought by .. Compaq? And then HP, now HPE.
Not a mainframe, but designed and built for 100% uptime. They used to do demos where you could open the cabinet and pull out boards at random, and it'd just keep going.
It migrated from custom hardware, to Itanium, to x86-64. It's a custom OS, but has a Unix-like layer on top for ease of porting stuff.
I used to work on NonStop. I wish it was better known, if only for the impressive uptime stories that did the rounds among the senior gurus. At least one involved firearms.
You rarely reboot the whole computer. You can take parts of it offline for repairs and the software will route around it. There is a PC inside it running Linux whose job is managing the various subsystems up from powering up the PSU, making sure UPS batteries are charged, that cooling is working even before the CPUs are powered up and microcode is loaded.
Every time I hear someone advocating for mainframes, they always praise them and make them appear as something like a computing behemoth, that, while expensive outperforms any commoditiy hardware at the tasks it's good at, wether it's in performance or reliability.
But there's never any real world use case. It's always just "If you're running a mainframe, you don't care about money". No performance benchmarks, no architecture comparisons. You get shown an architecture diagram of a mainframe, next to one of say, a cloud system and you get asked "See??", like the conclusion is obvious.
> Instead, we got lowest-common-denominator systems. Not what was best, merely what was cheapest, easiest, and just barely good enough – the “minimum viable product” that an industry of shysters and con-men think is a good thing.
How is this _not_ a good thing??
>But mainframes aren’t. They cost a lot, and rental and licensing costs a lot, and running them costs a lot… everything costs a lot. Meaning you don’t use them if you care about costs that much. You have other reasons. What those are doesn’t matter so much.
...which is exactly my point! Yeah it makes sense that there is a separate ecosystem for mainframes! Because from the outside and these kind of arguments it looks like IBM has been siphoning off some great marketing in the 80s and 90s and _really_ ignorant managers in charge of purchasing at large banks and the US gov.
On an unrelated note, I kinda made the experience that people that like mainframes usually have some weird obsession with high level computing architectures. Is there maybe a correlation?
IBM actually forbids customers from sharing the performance of its z/OS mainframe performance benchmarks, which should tell you that they must be terrible for the money.
The value proposition (if I may use that terminology) of mainframes is not performance -- it's 'RAS' (reliability, availability, serviceability). Of course, if you've got a huge legacy codebase of COBOL and CICS, it might be more a matter of 'keeping the lights on' for the business.
Also, benchmarks would have to be carefully set up. Sure you can do more MIPS on a cluster of generic underpowered x86 boxes, but what happens if you remove a RAM stick, shoot a bullet through an SSD or are hit by an earthquake? The numbers alone are hard to compare if the guarantees are totally different.
A second thing to count is that it’s vastly cheaper to run thousands of services out of a small group of very large machines than to run the same workload on a large number of cheap machines.
> No performance benchmarks, no architecture comparisons.
Yeah, I remember dipping my toes into this world when I was trying out COBOL a few years ago. IIRC they market these things with "transactions per second", which doesn't exactly lend it self to direct comparison with other systems...
> Every time I hear someone advocating for mainframes, they always praise them
[1] I wasn't "advocating" anything. I was talking about how they've survived. They have survived. Whether it's under emulation doesn't matter: still being sold, still driving the same peripherals from the same software.
Their survival, thus far, is a fact. So the question I was trying to address was why.
That's not advocacy.
[2] If I were, which I wasn't -- It is pretty hard to advocate for anything without praising it. :-)
The points about performance others have answered very well.
> How is this _not_ a good thing??
"You can have good, fast, or cheap. Pick any two."
We have fast and cheap.
The end.
> people that like mainframes usually have some weird obsession with high level computing architectures
Um. Define what you mean by "high level architectures" here?
Mainframes are supposed to be good at the type of jobs that you can't really do an apples to apples comparison of - they're not supposed to be running linear algebra benchmarks, however equally a lot of quasi-distributed systems (some cloud infra or whatever) performance will completely collapse when you try to scale them beyond little benchmarks.
I've read IBMs docs on their processor architectures, I'm sure they're fast enough but no more than that.
Wouldn't choose one for infrastructure but would love to have a play with a mainframe.
> I've read IBMs docs on their processor architectures, I'm sure they're fast enough but no more than that.
I’ve played with the LinuxONE community cloud for a while and one thing that quickly become obvious is how ridiculously fast the machines are. Not only the 5+ GHz CPUs but all that very smart IO that seems to magically predict what the CPU will want, and have it on hand.
And the cache architecture of the z16 CPU is awesome.
It is never an issue of “or” (select one) or “and” (select all) but to think in multiples (and not even necessarily ecosystem that is linked). The key is it is part of the solution to many different ad possibly unrelated problems.
Like playing with pi you have accessed to ports. And playing with mainframe they have access to lots of io ports. And controlled access to thousands of terminals. Pc is (in the older days) isolated calculation machine (excel/lotus 1-2-3/visicalc, words/WordPerfect and multimate/wordstars, real slides vs PowerPoint) and networked machine (unix, internet/decent and SNA). Many different species and some isolated and some linked.
Also there are many mainframe in the past if one refers to a machine which has lots of CICS system. Dos/vse is sort of mainframe. Even though it is much smaller than mvs. And music, vms etc.
The question is not why strange but rather can they have a place or a niche to survive. And if so, why. And if not really not. For example windows/NT to today windows servers are evolved like bird from the extinct dinosaurs called dec (at least the team is, dna or gene there but not the hardware).
If you want one ring (do they still use the most unreliable in operation due to its being most relatable designed token ring?) to rule it all, it is stil mainframe.
Strangely in the peak hour, we are considering the transaction processing system as mainframe is not that non-stop and the front end processor sometimes has to be non-mainframe.
One thing in perspective is that in 1960-2000 you can use that to handle thousands of terminals with only 16 MB memory. That niche is …
What does this have to do with mainframes other than the word "mainframe" is in the title and it links to a blog post where someone mentions Unisys. BeOS and OS/2 were operating systems that predominantly ran on PC class systems.
I'd like to see an article about the joys of mainframe operating systems that didn't survive.
I cut my teeth on a PR1MEOS machine at SUNY New Paltz. Great system. But there is no modern emulator and almost zero information about it on the internet.
I don't really share the reverence for mainframes. While they have certain cool unique features, like extreme resiliance, that doesn't matter very much because all the low-level details can be abstracted away. We have learned to build reliable systems on "commodity" hardware.
In all the other places where mainframes are different, they are not only utterly alien, but I would also argue inferior. Focus on 60s languages, weird menu-based OSes, no proper Unicode support (judging from plane tickets and payrolls with missing symbols), and so on.
That they hold out in "important" areas like banking and insurances is especially damning. This is the "allocation" layer of our society and is also hopelessly obsolete. The way we allocate resources has not caught up with our technological development. My personal belief is, one day, when we make the step to "capitalism++" - I don't know what it will look like, but it will compare to our current society like that compared to feudalism - then all that legacy infrastructure will become unneccessary.
A lot of the holdouts are specifically z/OS mainframes running TPF. It's a distinctly different OS than z/OS (what MVS is now called). Used by VISA and the Airline industry.
They've both had multiple attempts over the years to replace TPF, with varying degrees of success. Amadeus/Altea just barely finished getting rid of their mainframes. The other big GDS systems are still working on it.
I don't think it was lack of desire or commitment of resources. ITA spent quite a lot trying to replace it, with an unusual collection of the best/brightest, and was able to replace the shopping piece successfully, but stalled on commercial success of the booking part.
It's just a hard problem to solve. TPF is incredibly good at extremely high transaction rates in a distributed fashion with high reliability.
> We have learned to build reliable systems on "commodity" hardware.
It is still cobbled together, and it still doesn't compare with what a mainframe can offer in reliability, security, resource efficiency and technical debt.
Mainframes are the original computers, if anything the microcomputers are more alien. They had virtual machines from the early 70s, Z/OS can still run code from the 360 and maybe even the 1401, and it still has far fewer vulnerabilities, part from obscurity, part from a smaller attack surface compared to general public systems like Linux. Nothing wrong with CICS and 3270 either, which you seem to call "menu based OS". These are extremely resource efficient presentation layers.
Also, i and Z basically are turnkey systems. They require close to no sysadmin, you don't have to run after the latest update to fix the latest issue. How many vulnerabilities had to be patched in the 51 years of existence of the 3270 protocol?
I would trust a mainframe a lot more than a cloud based, or worse, anything based on Linux or Kubernetes when it comes to reliability and security - in fact, I bet an app running on such a solution will be considered obsolete in a mere 15 years (if not 10).
I've seen companies running their own internal mainframe classes just because there's no suitable alternative to replace them.
You might as well say that battle tanks are better than Toyota Corollas. I'm sure a battle tank is safer in an accident but that doesn't mean it's the best choice for a daily driver.
The goal of a business is to produce as many outputs as possible with as few inputs as possible.
If mainframes are so much better, why don't you own one? Why doesn't your company own one? I see a Z 2828 on eBay for $9,995, sounds like a pretty good deal! I know the Raspberry Pis that run my self-hosted services only cost me $200, but, like you said, you get what you pay for! Where the heck is my credit card!?
Mainframes are a dying breed because they aren't a solution for 99.9% of businesses (yes, that's right, literally 99.9% of businesses have fewer than 500 employees). [1]
By the time a new business has grown large enough to potentially benefit from a mainframe architecture, it has been using x86/ARM commodity computing for years/decades.
The only way a business would ever choose mainframes would be if they were already gigantic businesses before microcomputers were invented and their business has a high amount of clerical overhead. This is why banks and airlines ended up with mainframes.
Having the best, most resilient technology possible isn't the end goal of most businesses. The goal of a business is to sell things and make money. Computing is essentially a cost center where the lowest bidder wins, where the cheapest possible solution is always the best one as long as the level of risk is acceptable.
> By the time a new business has grown large enough to potentially benefit from a mainframe architecture, it has been using x86/ARM commodity computing for years/decades.
And this is why I say IBM is failing terribly in providing a simple onboarding ramp to these platforms. Almost nothing will scale as far up as a Z, but almost no company will need that and spending the money required by the entry level mainframe is a capital expense most companies won’t consider appealing.
In my opinion, the marketing and legal group at IBM (for decades) must have this for their mission statement: "Let's see how quickly we can sink this business!". They're completely inept.
Examples?
- Customers: "Can we license z/OS, z/VM, and other IBM mainframe software to run on Hercules (mainframe emulator) for DR purposes?" IBM: "we'll sue your ass out of existence!"
- POWER5 brought some pretty amazing virtualization technology allowing for 'micro LPARS' down to 1/10 of a CPU [0]. It's gotten even better since then. When and where have you ever heard about these capabilities? They're part of what used to be called APV (now branded as PowerVM) [1].
- At one time you could buy a used RS/6000 off of eBay (or from a reseller) and get a legal license (and media) for AIX. To do this today with modern Power systems, you have to first put the hardware under maintenance agreement. Oh, and if the server wasn't already under a maintenance agreement ('SWMA') (or there's been a lapse since it was under maintenance), you have to pay an additional fee ('ALF'). How much are these fees? SWMA estimate is $1800 PER YEAR. ALF estimate is $3200 (one time, unless you have a lapse in SWMA and need to do ALF again). Since Power8, you have to buy a separate HMC (nearly $2000) to configure LPARS. Net result is that it has become cost prohibitive for individuals to buy a second-hand POWER system and run latest AIX or i.
- Want to get IBM's C or C++ compiler for AIX? There are 3 pricing options [2] available: $5780 per user, $17500 per concurrent user, or $88.60 per VPC per month.
It must indeed be very frustrating to work for IBM and want to cover different markets and being unable to do it.
I see, however, IBM can migrate a lot of those products from item sales to cloud subscriptions and, in that case, there would be little space for entry level hardware.
That was a wild ride – from a reasonable start of "mainframes are a sub-optimal compromise" via "important foundations of our society rely on obsolete systems" all the way to "we'll replace capitalism with something completely different and better, but I don't know what".
I think one cannot understand the usefulness of mainframes without adding data integrity to the picture.
Let's take a bank or an insurance company. For them, data integrity is of utmost importance. If you miscalculate bank account balance or insurance payment by one dollar, you erode trust, which is the most important asset they have.
You will have data in multiple systems, none of which have the complete picture of all the data. So you need data integrity over multiple systems.
Most modern architecture books recommend REST microservice architecture and "eventual consistency" approach to data integrity. The use of "sagas" is recommended for implementing this data integrity. However, this is not enough if you have high on-line data integrity needs, such as the banks have. And even if your needs are not as high, it is very difficult to get eventual consistency "right".
On mainframe platforms, you have TP monitors (such as IBM CICS). Within TP monitors, you implement services, which is very similar to "serverless functions" such as AWS Lambda, but with distributed transactions.
These TP Monitor services may be distributed across multiple physical "servers", and we can scale up the number of these services if needed. The platform provides reliability that is easily as high as AWS Lambdas. Also, you don't need to deal with the container startup time issues or pay for the container virtualization overhead.
But the biggest benefit TP Monitor services have over modern "serverless functions" is the support for distributed transactions. I can call another service from within a service inside the context of the same global transaction, and the platform will take care of the distributed global transaction handling for me. This is essential when you need to guarantee high data integrity over various systems.
There is at least one TP Monitor (Oracle Tuxedo) that runs on Linux as well, but if you look at the tooling, it resembles more the mainframe world than modern development.
In my understanding there is no modern platform with this kind of data integrity guarantees.
(Caveat: Although I am involved in a mainframe modernization project in a company in a related field, my knowledge of mainframes is fairly limited.)
Back when IBM changed the branding on their hardware lines, it was done to help people identify WHY you would pick one platform versus another.
z (mainframe) = "Zero downtime"
i (as/400) = "integrated" (e.g., DB2 and stuff like processing queues is baked into the OS)
p (rs/6000) = "performance"
x (x86) = was sold off to Lenovo after a few years
See the "p"? If you need maximum performance, you go with POWER and run AIX or Linux.
Unless understand your comment wrong: most older EU banks run their core on mainframe. Sure the webapp to see your account is running on some websphere/j2ee or nowadays maybe even angular server. But that's just a gateway to the real accounting system on the mainframe.
Brazilian banks and parts of the government were pretty big mainframe clients. I’m most familiar with the IBM ones, but Unisys also had quite a footprint with their A series (which evolved into the Clearpath Libra family).
In jest I'll also assume the author could write a similar article lamenting what storage tech could have been, but instead everyone with data that mattered took the maintenance hit with RAID and called it a day.
Commoditization is, to me, just a natural effect of product development in a free market, capitalist(-ish) society. It feels to me that as long as much of the population is chasing financially optimal outcomes this will continue to happen, and that may be okay.
I suppose I am a grumpy old git, then, although I did not think of myself that way until recently. In the past decade or two, I've seen computer science lose its collective appreciation of the staggering potential of hardware. This has steadily resulted in software being built with tremendously over-engineered, hyper-complicated, cloud-first architectures that barely match the throughput of a single box running a high-performance platform (and for the record, "high performance" can still be relatively ergonomic via Java, C#, Rust, and so on).
The scale of hardware, clock cycles, bits per second of bandwidth, etc., being squandered on modern cloud-first highly complicated architectures boggles the mind.
I fear there is no strength behind any pendulum swing back to architectural simplicity, appreciation of the available capacity of hardware and how to use it, and local-first.