My Master's supervisor, at Wits university in Johannesburg, worked on the architecture of the 360 after graduating from the PhD program at Harvard. I remember him telling us how they went about deciding whether or not 32 bits would be a sufficient size for "most" floating point numbers. They were very systematic about it, scouring journals, talking with physicists and mathematicians and so on.
(1) Maybe I'm just a little too young but my impression was that the 360 and it's successors were not that big in scientific computing, certainly there were some big academic installations but I saw a lot more DEC machines (PDP-8 in the experimental lab, PDP-10, PDP-11 and VAX elsewhere) and by the time I went to college circa 1990 you were likely to see Motorola 68k-based "workstations" that were quickly replaced by RISC architectures like SPARC and PA-RISC which in turn failed to compete with the PC.
Cornell had one of very few IBM 3090s with a vector unit (to compete with the Cray) just before I showed up, but when I did IBM had donated a message-passing based supercomputer based on the Power PC architecture. I only saw a 3090 (no vector unit) at New Hampshire Insurance which I got to use as a Computer Explorer.
(2) I was taught in grad school in the 1990s to use floats if at all possible to reduce the memory requirements of scientific codes if not actually speed up the computation. (In the 1990s floats were twice as fast as doubles on most architectures but not the x86). I really enjoyed taking a course on numerics from Saul Teukolsky, what stood out in the class as opposed my reading to the Numerical Recipes book which he was a co-author of, was the part about the numerical stability of discretizing and integrating partial differential equations. If you did it wrong, unphysical artifacts of the discretization would wreck your calculation. Depending on how you did things rounding errors can be made better or worse, Foreman Action's Numerical Methods that Work and later Real Computing Made Real reveal techniques for managing these errors that let you accomplish a lot with floats and some would point out that going to doubles doesn't win you that much slack to do things wrong.
The 360 was pretty big in high-energy physics. The numerical libraries used at the time (KERNLIB, some of which found its way into BLAS) were all written within the limitations of FORTRAN 77, something that was not needed for the VAX.
TIL that not only the software side was chaotic (served as the backdrop of Fred Brook's "Mythical Man Month"), but also the hardware side almost failed.
the article here ends around 1971 --- the mainframe would later save IBM again, twice, once when they replaced aluminum with copper in interconnects, and then when some crazy IBM Fellow had a team port Linux to s390. Which marked the birth of "enterprise Linux", i.e. Linux running the data centre, for real.
> Or was it the gradual phasing out of mainframe-class hardware in favour of PC-compatible servers
Proprietary Unix is still around. Solaris, HP-UX and AIX still make money for their owners and there are lots of places running those on brand-new metal. You are right, however, that Linux displaced most of the proprietary Unixes, as well as Windows and whatever was left of the minicomputer business that wasn't first killed by the unixes. I'm not sure when exactly people started talking about "Enterprise Linux".
Back then I went with Debian, but I agree - the early scale-out crowd went mostly with Red Hat. Back then there was a lot of companies still doing scale-up with more exotic hardware with OSs like AIX and Solaris.
I first remember the term when Oracle ported themselves to Linux, began submitting patches, then began pushing Oracle on Linux to enterprises.
Oracle's big reason for doing so was because they could charge more for Oracle on Linux, and still get to a lower total cost of ownership than Oracle on Solaris.
Oracle began this in 1998. By 2006 they had their own Oracle Enterprise Linux distribution.
well, IBM very publicly invested 1Bn USD into supporting Linux on all their hardware with all their software. so db/2 on s390 on Linux, likewise websphere, etc. it gave the customers the promise of one run time environment on anything. and SUSE and shortly later Red Hat provided truly source compatible environments for software vendors. "code once run anywhere", for real. and then IBM and Oracle and Co forced suse and red hat to become binary compatible at the kernel/libc and basic system libs level, so Oracle and all could provide one binary under /opt on any Linux...
and that pulled all other vendors along, HP, Dell, Fujitsu, likewise for software...
and it all started with IBM officially supporting and pushing the hobbyist student project Linux on the holy Grail of enterprise compute, (of 1999/2000): s390
4.3BSD was basically designed without any bespoke hardware platform of its own. They commandeered DEC’s big iron, for the most part, to “dual boot” before dual-booting was cool. 386BSD began to enable PC-compatible hardware and really cost-effective “server farms” even before Linus was a twinkle in Finland’s eye.
Moreover, various BSD flavors were empowering admins to breathe new life into legacy hardware, sidestepping and bypassing the proprietary software channels. Linux, on the gripping hand, remained x86-unportable for awhile after BSD (and Xfree86) was running everywhere.
Personally I ran Minix-286 at home; at university we enjoyed a “recreational” VAX11 running not VMS but 4.3BSD.
Flash forward to 1998: from the arid but air-conditioned Sonoran Desert I received gently-loved twinned Apollo 425t systems with memory upgrades; I installed OpenBSD on both, as well as my 486DX100! It was a homogeneous OS environment with heterogenous hardware... and the 486, with Adaptec SCSI & a VLB #9GXE64 Pro, could boot into Windows 98 and run the Cygwin X server, or DOOM or Quake.
There was a golden age when a dude could walk into any surplus yard, grab Big Iron Unix Boxes, take them home and bootstrap NetBSD. On anything. Bonus: BSD originated in USA/Canada, for a trustworthy chain of trust. (Oh Lord, the encryption export technicalities...)
BUT. I worked at a place that used IBM 360s. We ran stuff for engineers, a lot of Fortran along with assembly code. We had so much stuff going on we could not code up and run things fast enough. The engineer/scientist got frustrated.
Then one day an engineer brought in an Apple II from home and ran the programs on that.
The earth shook. The very ground beneath us moved. Tectonic plates shifted. The world was never the same again! I think it was Visicalc.
Later there were other things. Soul Of A New Machine. The Mac.
I wonder how the compute power of a current high end smart phone compares with and IBM 360? I know the graphics chip is better.
I wonder how the compute power of a current high end smart phone compares with and IBM 360? I know the graphics chip is better.
A current high end smartphone has around 10 billion transistors.
From https://gunkies.org/wiki/IBM_System/360, IBM made 11-12 million SLT modules per year in the late 1960s, with less before that. Each individual SLT module contained a handful of transistors. Therefore, in transistor count alone, a single smartphone has more transistors than IBM produced through the 1960s. And this is before we consider the fact that clock speeds today are much higher than they were in the 1960s.
Your smartphone literally has enough hardware to outcompute the entire world circa 1970.
Isn't it amazing what over 50 years of Moore's Law can do?
My home NAS in the other room could hold about 350 million C64 floppies. I've sometimes wondered how that compares to the world's floppy disk manufacturing capacity in 1982.
I also appreciate that my Internet connection is about 33 million times faster than my first modem. It'd take me over a year to download what I can slurp in about 1 second now, even if I could afford the 7 thousand floppies it'd take to store it.
Indeed. I find it interesting to look at the generational outliers on that curve: The Cray-1 wasn’t eclipsed in raw FP compute by a consumer system until the Pentium more than 15 years later.
Most of the outliers look like, "Someone was willing to spend large amounts of money."
Another outlier was Deep Blue. Estimated cost of about $10 million. Its estimated strength was matched by top end PCs about 9 years later. Your phone today is better than those PCs.
What’s the average IPC of these chips for a reasonable workload?
Early processors were typically 1 or lower. Modern stuff is all superscalar piplined and out of order and can do way more than you’d expect. Not to mention SIMD operations and other technologies. Branch prediction is probably better on the new chips too.
And with more RAM and cache algorithms can be chosen with different tradeoffs for less instructions.
16 cores at 4ghz was a thing like a decade ago - chips today might have the same specs but are definitely far faster.
WOW! IPC, instructions per cycle? Sure, back in those days, usually how many cycles per instruction! The 360/91 was a high end thing, said to cost $13 million. One was at the Navy lab, JHU.APL. As I recall, it could do 1 floating point (32 or 64 bits?) instruction per cycle and sometimes 3 in 2 cycles.
Huh. The article claims at least an order of magnitude more SLT modules than the reference I found. I think it is still quite a bit less than the smartphone, but that makes global compute at least closer.
Still, 55 years of doubling transistors at a given cost every 2 years is about a 190 million fold transistor difference for a given cost. Clock speeds have improved by a factor of 1000 on top of that. Even with performance tradeoffs for battery life in a smartphone, there is no surprise that the phone should have more compute power than the world did in 1970.
If I had to compare computers based on one number it would be the amount of RAM. The 360 had a 24 bit address space which could fit 16MB of RAM although only the largest installations, like the one at NASA, were that big. iPhone 16s have 8GB of RAM so you're talking 512 times the memory capacity, never mind that my desktop PCs are all loaded with 4-8x times that of the phone and you can definitely get a big server with a few TB.
An IBM 360/20 on the small side, however, ranged from 4kB to 32kB which was similar to home computers circa 1980, before it is routine to have a complete 64kB address space.
Where the 360 crushed home computers was in mass storage, 9-track tapes could store 80MB contrasted to floppy disks that stored less than 200kB. Large storage compared to memory meant a lot of focus on external memory algorithms, also there was already a culture of data processing on punched cards that translated to the 360 (e.g. terminals have 80 columns because punched cards had 80 columns)
Where the 360 crushed home computers was in mass storage
Well...sure, you could put bigger storage on a mainframe. It's just money, after all. But you could put a tape drive on a home computer. And bigger disks. And a card reader, for that matter. Where the 360 really crushed the home computer was in aggregate bandwidth, via the Channel architecture. An Apple 2 could just about keep up with a floppy and a display. A 360 could keep up with dozens to hundreds of tapes, disks, card readers, terminals, printers and other things all at the same time.
Large storage compared to memory meant a lot of focus on external memory algorithms
I would agree with that. I would just argue the real mainframe advantage is a whole-system one and not point to a single factor (memory size).
Comparing like-for-like (tape storage), you can now buy 45TB tape cartridges. That's a 500,000 times improvement per tape.
Edit: apparently these cartridges actually are 18TB, 45TB is "compressed" capacity. Still though, terrible marketing aside it's still factor of 225,000.
Well, the VAX was there before any of these, but I wouldn't call that a "personal machine."
I suppose the argument could be made that the 68000 was first, as both it and MIPS ended up in gaming consoles (Sega Genesis vs. Sony PS2 and Nintendo 64).
However, MIPS eventually scaled to 64-bit, was well-known and heavily exploited in supercomputing applications, and was used to produce the film Jurassic Park. The 68000 had a far dimmer future.
Yes, the x86 line did supplant them all, but only with AMD's help. Had Itanium been Intel's final answer, MIPS might be much stronger today.
>BUT. I worked at a place that used IBM 360s...Then one day an engineer brought in an Apple II from home and ran the programs on that.
The 360 was introduced in 1964. The 370 was introduced in 1970. The 3033 was introduced in 1977. The Apple 2 was introduced in 1977. So, yeah, if you were still using 360s contemporary with an Apple 2, no wonder the engineers were frustrated.
Lots of organizations run those computers for very long times. It was not unusual for a medium-sized company, a factory or some local government to be running 10 to 15 years hardware.
The most powerful 360/91 was roughly equivalent to a 20MHz 486 from the early 90s.
Mainframes had much more powerful distributed IO for multiple hard drives, tape systems and such.
But the CPUs were really not all that powerful at all.
Many people wildly underestimate just how insanely fast and power-efficient today's commodity computing is compared to high-end supercomputing from earlier decades.
A Raspberry Pi destroys any supercomputer earlier than around 1990, and gives some later models a run for their money.
An Apple S7 watch processor is maybe 25X faster than a Pi 5.
I am not sure about the 360’s terminals, but some terminals could display graphics via sixels. Konsole and xterm are capable of showing them in the present day if you run a terminal copy of word perfect.
Alan Kay has promulgated many famous truths about computer science - one of them being that among all fields of study, it has the least regard for the people and discoveries that brought it to where it is today. Maybe it's just my own sense of history as I move into my 4th and likely last decade of working with computers, but I find this to be both true and lamentable.
How many of the people who made the steam engine possible do we remember? James Watt of course, but many many people were making contributions in material science, needed to make them useful. Not to mention many advances in values. No doubt lots of other areas as well, but I'm no expert in the steam engine.
Not sure what you mean by this - it's not as if steam engines are an extensive technology today, and certainly no university is teaching "steam science", while nearly every school is teaching "computer science".
Perhaps this is just the attitude that drives Mr. Kay's point home - do individuals who are interested in CS have little value for who and what has come before them?
To be fair, everybody who takes a thermodynamics course owes 90% of it to the 'steam science' pioneers. Understanding what determines and limits the efficiency of heat engines was as big a deal in its day as the WWW is in ours, but unlike our own era, a lot of brand-new science and math had to be discovered by those engineers.
Steam tech is much, much more interesting than it appears at first.
Sure they do, it's just called fluid dynamics and thermodynamics. Enough to fill up about 1/3 of a mechanical engineering degree, if you're really into it (most aren't).
Not that there's a lot of historical context to things as far as which people did what - most of that sort live on in names of techniques and methods (Rankine cycle, de Laval turbine, Carnot efficiency, etc.)
they also moved on three more CPU generations since that redbook, to z17.
I think it's Linux on Z that makes it sexy and keeps it young, in addition to a number of crazy features, like a hypervisor that can share CPUs between tenants, and a hardware that support live migration of running processes between sites (via fibre optic interconnect) and the option to hot swap any parts on a running machine.
It's doing a number of things in hardware and hypervisor that need lots of brain power to emulate on commodity hardware.
_and_ it's designed for throughput, from grounds up.
Depending on your workload there may be very good economical reasons to consider a mainframe instead of a number of rack-frames.
>Depending on your workload there may be very good economical reasons to consider a mainframe instead of a number of rack-frames.
For legacy companies yes but it would be very hard for new YC companies or existing non-mainframe companies to create a spreadsheet showing how buying a new IBM Z mainframe would cost less than the latest commodity x86 or ARM servers in the cloud or on-premise.
The IBM pricing for mainframes makes sense for legacy companies like banks and airlines with a million lines of old COBOL code that want to keep it all running with the latest chip technology. (The mainframes from a few years ago are coming off the lease and they need to upgrade to whatever new mainframe IBM is offering and sign another lease & service contract.) So, IBM mainframe prices are very expensive -- but legacy companies will pay it because migrating the code away from mainframes can be even more expensive.
It's similar to expensive enterprise pricing of Oracle, Embarcadero Delphi, Broadcom etc that takes advantage of existing customers already locked into their products. Virtually no new tech startup with a greenfield project is going to pay Delphi $1599-per-seat for each of their developers. Only existing customers stuck with their investment in Delphi code are going to pay that. (https://www.embarcadero.com/app-development-tools-store/delp...)
But some companies do endure the costs of migration to get out from IBM lock-in. There are lots of case studies of companies shifting their workload from mainframes to AWS/GCP/Azure. I can't think of a notable company that did the reverse. Even a mainframe hardware vendor like Fujitsu quit making mainframes and shifted to x86 running an emulation of their mainframe os.
Yes, IBM mainframe can run other workloads besides COBOL like Java and C/C++ but no company that's not already using mainframes would buy & deploy to IBM's Z hardware for that purpose.
in a nutshell a mainframe is a cloud in a box for high throughput workloads which need crypto and tpu accelerators.
mainframe pricing usually is not by pound of iron but per cpu cycle. unless you say nah I'm buying the thing, not just cycles. soyou have a choice of cloud pricing or hardware pricing.
for significant pure Linux workloads that need an own on premise cloud the TCO pricing is surprisingly competitive with any home grown solution.
even if you don't _need_ an own on premise cloud, AWS and similar donate come for free and there may be a break even there, too.
that said, legacy host software, Delphi, cics, Oracle, DB/2, cobol etc, you named it, yes that's a different story, with all the extra software licensing.
but a pure Linux mainframe is surprisingly competitive not just in compute and throughput but also in pricing.
plus you get quite some high availability in silicon. think ECC on the ALU, hot stand by spare CPU, multipath everything, if your business depends on uptime your system architecture becomes much simpler on highly dependable hardware.
so that spreadsheet compares own people and software construction vs IBM tax in some columns.
>but a pure Linux mainframe is surprisingly competitive not just in compute and throughput but also in pricing.
It's not competitive when you consider what long-time IBM mainframe customers actually do. E.g. SABRE airline and travel reservation system was one of the first IBM mainframe customers in 1960 with the IBM 7090 and then upgraded to System 360 and then the newer Z mainframes. SABRE's multi-decade experience with IBM mainframes with mission-critical business applications means they are one of the world's foremost experts on its capabilities & costs that's not biased by any IBM marketing or sales pitches.
Even with all that in-house experience, SABRE still chose to gradually migrate off of IBM mainframes to less expensive tech stacks. Some have touted IBM's TPF (Transaction Processing Facility) on the mainframe as compelling technology but that still didn't dissuade SABRE in ~2001 when they migrated the airfare pricing application to Tandem (Compaq/HP) NonStop servers running UNIX. (https://www.computerworld.com/article/1339621/has-mainframe-...)
> We moved 93% of compute capacity from physical data centers to the public cloud, resulting in a 50% decrease in our compute costs.
> We migrated more than 120 million bookings from a mainframe-based system to one using Google Cloud’s Spanner database, without impacting customer operations.
JP Morgan Bank is another example of migrating from IBM mainframes to cloud. If anyone out there truly thinks that running a new greenfield Linux workload will be be cheaper or even cost-competitive on a new IBM Z mainframe, just pause and consider if you truly know something about IBM mainframes' OpEx that multi-decade IBM customers like SABRE and JP Morgan don't already know.
Why would any new customers in 2025 willingly buy into IBM Z mainframes if they see existing customers spending billions trying trying to move off of them?
I’ve had to budget a line of business app that runs on both z/OS and AWS. Reliability for both hit an asymptote somewhere around 2019. The opex price crossover happened somewhere around the same time, depending on the customer.
Nearly every installation site and their internal support director agrees that the z/OS installations are far less expensive to support, simply because the minimum level of experience for a z/OS engineer is about a magnitude more than a cloud engineer.
It’s a risk issue. 5 year high risk projects aren’t appealing to CIOs with an average tenure around 18-36 months. Even if it works, why should the next asshole get the credit?
I think the point is that IBM’s market is shrinking, and they can’t acquire new customers. They will eventually need to stop making mainframes because there will be a crossover between the cost for new mainframes for remaining customers vs transition to commodity hardware cost.
Virtually no new tech startup with a greenfield project is going to pay Delphi $1599-per-seat for each of their developers. Only existing customers stuck with their investment in Delphi code are going to pay that.
I agree with this, and all your other reasons why mainframes will remain legacy platforms.
But man, how crazy is it that an industry that is 100% productivity driven and (until AI data centers, at least) labor-cost-constrained would snub its nose at paying a fraction of a percent of those developers’ salaries to put good tools in their hands.
I suspect the main reason isn't just strictly economical. If you are Google or some such you can probably compensate by building smart software around commodity hardware, but most companies simply can't. Even if they have boatloads of money (banking, insurance) and can hire expensive talent, they simply can't successfully complete such an undertaking because they don't have it in their DNA, and management isn't incentivised to take on such a risky project.
In this case they will just use a mainframe, even it isn't cheaper in the long run.
Thing is Google does not use commodity hardware for their DCs as far as I can tell. They got famous for that back in the early 2000s but I think they abandoned that approach a long time ago.
They may design their own hardware, but their approach to scaling and fault tolerance is still the same: not a low number of fast and very expensive enterprise grade hardware that is unlikely to fail, but a huge fleet of servers that scale horizontally and that can tolerate the loss of a machine.
Which is the Mainframe vs commodity server dichotomy.
> I think it's Linux on Z that makes it sexy and keeps it young
They feel fantastic when running Linux, but, if you don't need all the reliability features that come with the platform, commodity hardware might be a better choice for the kind of workload that has evolved on Linux.
> Depending on your workload there may be very good economical reasons to consider a mainframe instead of a number of rack-frames.
Absolutely - it makes a lot of the administrative toil disappear. I know clusters are sexy, but getting the job done is always better.
Other than IBM’s absurdly high pricing, they’re cheaper to run in almost every way than x86 machines (including cloud). I haven’t done the math to compare with aarch64/ARM.
But most people don’t want to deal with the hassle of dealing with IBM.
Do you have resources that provide info on companies using Linux on Z and the benefits of this verses commodity hardware? I used to work for a Mainframe ISV but the majority of our software ran on z/OS. I only saw customers using Linux on Z to begrudgingly run software that wouldn't efficiently run on z/OS, mainly Java applications when customers didn't want to deal with the complexity of specialty engines. I realize because our software focused on z/OS I had limited visibility into the full operations at our customers.
the advantage comes with the full package, operations and all.
you don't have racks with blades but one box or two, that you upgrade every few years and other than that your hardware side is covered.
rewiring networks, reattaching storage etc all remotely, CLI, and most importantly you only pay what you use.
you need one guy or a consultancy for the initial etc up and for fancy Config changes but once it's essentially set up you simply have a large Linux data centre and do Linux stuff.
oh and you can hot plug additional physical CPUs into a running VM and pull it out and reassign when it's not needed, likewise RAM. that's somewhat difficult with commodity hardware.
and there _are_ companies that value this and choose Linux on Z as a pure Linux deployment.
but you have a point. if nobody in the building knows this, nobody's gonna call IBM and ask for a quote. it's simply not on anybody's radar.
> Depending on your workload there may be very good economical reasons to consider a mainframe instead of a number of rack-frames.
This may be true, but because there's basically no on ramp to running on a mainframe, there's no way anybody is going to try it unless they're already on a mainframe. Or maybe unless they really need something that only a mainframe can provide. But most companies can live with some downtime, and once you can live with some downtime, you have options for migration between sites, and options for migrating loads so you can swap parts on a stopped machine. Splurging on network infrastructure with multi-chasis redundancy is an easier step to take to get to a more reliable system than building against a totally different system architecture.
> This may be true, but because there's basically no on ramp to running on a mainframe
You can get a partition of IBM Z to run in the cloud. The cost is about $5/hr for the smallest configuration.
> Splurging on network infrastructure with multi-chasis redundancy is an easier step to take to get to a more reliable system than building against a totally different system architecture.
Yes and no. If you truly need that redundancy than the mainframe is going to provide a much better version of it. SYSPLEXs and LPARs are some insanely powerful technologies.
A mainframe is the biggest single system image you can get commercially. It's the easiest, most reliable way to scale a classical transactional workload.
> A mainframe is the biggest single system image you can get commercially
It depends. As we have seen the other day, HPE has a machine with more than 1024 logical cores, and they have machines available to order that can grow up to 16 sockets and 960 cores on a single image of up to 32TB of RAM. Their Superdome Flex goes up to 896 cores and 48TB of RAM.
I believe IBM's POWER line also has machines with more memory and more processing power, but, of course, that's not the whole story with mainframes. You count CPUs that run application code, but there are loads of other computers in there doing a lot of heavy-lifting so that the CPUs can keep running application code at 100% capacity with zero performance impact.
> It's the easiest, most reliable way to scale a classical transactional workload.
And that's where they really excel. Nobody is going to buy a z17 to do weather models or AI training.
My partner makes a living writing z/OS assembly language, has been for many years now. The platform is still going strong as a business. The main problem they face is all the folks who know how to program these things are retiring (or dropping dead at their keypunches.) It's very hard to convince new people to learn how to operate these systems.
For your partner's sake I hope you're right but is z/OS as a platform actually continuing to grow, or are they just having a hard time filling seats because it's hard to see a long and profitable future working on (what some might call) "legacy" systems?
When I was growing up (decades ago, mind), my dad kept trying to convince me to get into machining. Lathes, mills, tool and die making, etc. In his line of work, he saw lots of machining companies basically paying all education and training expenses for new hires because their experienced old timers were retiring faster than they could be replaced. (He also thought computers were a fad...) I'm sure it was a good opportunity at the time. But nearly all of those companies eventually closed up because offshore manual labor was and still is way cheaper. If I'd had taken his advice, I'm pretty sure I would have had to reboot into another career at least once by this point.
He does system level stuff, enhancements to IBM's z/OS. A lot of their customers are big financial institutions, banks and the like that use MVS for transaction processing. His software augments the operating system and isn't application specific.
The reason the tape drives are in those tall enclosures are the vertical channels below the tape reels. That was for slack in the tape, there was a loop of tape hanging in each of the channels, so that tape reads and writes could be stopped and started faster than the heavy tape reels could stop and start.
My sister worked at IBM and one of my favorite stories is when Lotus tried to pressure IBM to spend millions on licensing, a few engineers went off and built their own spreadsheet application and IBM told Lotus to piss off.
To add to this: they had $750 million in 1963 dollars, in parts and no shipping computers; inventory control was so bad that they had to have guys with clipboards to physically go into the warehouse and count parts.
They announced it and started getting a huge number of orders; IBM hired 1000 people a month and kept up that pace of hiring for 5 years.
The well known book "The Mythical Man Month" is in large part based on the author's experience as one of the top people on the System 360 project, and what went wrong during the effort.
Thomas Watson, Jr.'s A Business and Its Beliefs was published in 1963 and makes no allusion to the S/360 work. It makes for curious reading today, for unrelated reasons.
Now, reading the article, this "[rivalry].. So intense was it that sometimes it seemed to exceed the rivalry with external competitors.” reminded me of something old about Motorola.. where rivalry went to the need to reverse-engineering other depts' chips via 3rd party acquiring them..
z boxes use a flavor of VM to run all the LPARS and allocate memory and devices. z/OS, z/VM and Linux all run as VMs.
Then there's CMS which runs under VM; theoretically it could run as an LPAR, but I've not seen that as running DIAGNOSE (VM system call) to the LPAR hypervisor could be disruptive. It would be interesting to drop DIAGNOSE into a z/OS environment, but I suspect it would be intercepted.
I much prefer z/VM to z/OS as a development environment. At one shop, I developed products under VM for deployment under both VM and MVS.
Many early S/360 installations ran 7070 and, I guess, 1401 emulators.
Eventually with VM, the SIE (Start Interpretive Execution) instruction appeared. A form is running LPARs.
Fascinating look at the challenges and risks IBM took on with the System/360. Betting the company on a compatible mainframe family was visionary but nearly disastrous. It's a testament to the importance of strong technical leadership, teamwork and perseverance to bring revolutionary products to market.
It was a business decision driven by Tom Watson Jr. after listening to a lot of customer feedback. See "Father, Son, and Co." https://www.amazon.com/Father-Son-Co-Life-Beyond/dp/05533808... his autobiography of his years at IBM, and beyond. The 360 project figures prominently.
My Master's supervisor, at Wits university in Johannesburg, worked on the architecture of the 360 after graduating from the PhD program at Harvard. I remember him telling us how they went about deciding whether or not 32 bits would be a sufficient size for "most" floating point numbers. They were very systematic about it, scouring journals, talking with physicists and mathematicians and so on.
(1) Maybe I'm just a little too young but my impression was that the 360 and it's successors were not that big in scientific computing, certainly there were some big academic installations but I saw a lot more DEC machines (PDP-8 in the experimental lab, PDP-10, PDP-11 and VAX elsewhere) and by the time I went to college circa 1990 you were likely to see Motorola 68k-based "workstations" that were quickly replaced by RISC architectures like SPARC and PA-RISC which in turn failed to compete with the PC.
Cornell had one of very few IBM 3090s with a vector unit (to compete with the Cray) just before I showed up, but when I did IBM had donated a message-passing based supercomputer based on the Power PC architecture. I only saw a 3090 (no vector unit) at New Hampshire Insurance which I got to use as a Computer Explorer.
(2) I was taught in grad school in the 1990s to use floats if at all possible to reduce the memory requirements of scientific codes if not actually speed up the computation. (In the 1990s floats were twice as fast as doubles on most architectures but not the x86). I really enjoyed taking a course on numerics from Saul Teukolsky, what stood out in the class as opposed my reading to the Numerical Recipes book which he was a co-author of, was the part about the numerical stability of discretizing and integrating partial differential equations. If you did it wrong, unphysical artifacts of the discretization would wreck your calculation. Depending on how you did things rounding errors can be made better or worse, Foreman Action's Numerical Methods that Work and later Real Computing Made Real reveal techniques for managing these errors that let you accomplish a lot with floats and some would point out that going to doubles doesn't win you that much slack to do things wrong.
The 360 was pretty big in high-energy physics. The numerical libraries used at the time (KERNLIB, some of which found its way into BLAS) were all written within the limitations of FORTRAN 77, something that was not needed for the VAX.
> 360 and it's successors were not that big in scientific computing
I do believe that is true.
IBM did have the Model 90 series, which was on the way to being a supercomputer.
Bur during that time CDC with the 6400/6600 etc was likely bigger in scientific computing.
The 360 played a pivotal role in the Apollo program.
TIL that not only the software side was chaotic (served as the backdrop of Fred Brook's "Mythical Man Month"), but also the hardware side almost failed.
the article here ends around 1971 --- the mainframe would later save IBM again, twice, once when they replaced aluminum with copper in interconnects, and then when some crazy IBM Fellow had a team port Linux to s390. Which marked the birth of "enterprise Linux", i.e. Linux running the data centre, for real.
> [Porting Linux to s390] marked the birth of "enterprise Linux", i.e. Linux running the data centre
Did it though? Or was it the gradual phasing out of mainframe-class hardware in favour of PC-compatible servers and the death of commercial Unices?
> Or was it the gradual phasing out of mainframe-class hardware in favour of PC-compatible servers
Proprietary Unix is still around. Solaris, HP-UX and AIX still make money for their owners and there are lots of places running those on brand-new metal. You are right, however, that Linux displaced most of the proprietary Unixes, as well as Windows and whatever was left of the minicomputer business that wasn't first killed by the unixes. I'm not sure when exactly people started talking about "Enterprise Linux".
Redhat was doing enterprise Linux well before IBM was involved. It was the rational platform for non-legacy .com 1.0 businesses.
> 1998: Many major companies such as IBM, Compaq and Oracle announce their support for Linux.
-- https://en.wikipedia.org/wiki/History_of_Linux
It was all about Solaris, AIX and HP-UX for .com businesses.
I was there, our Linux deployements were only used internally, we never sold those workloads as UNIX targets on our product.
Back then I went with Debian, but I agree - the early scale-out crowd went mostly with Red Hat. Back then there was a lot of companies still doing scale-up with more exotic hardware with OSs like AIX and Solaris.
nope.
the first enterprise Linux was SuSE on s390, then came RH on x86 and then suse there as well. but RH marketing was better back then already :-D
I first remember the term when Oracle ported themselves to Linux, began submitting patches, then began pushing Oracle on Linux to enterprises.
Oracle's big reason for doing so was because they could charge more for Oracle on Linux, and still get to a lower total cost of ownership than Oracle on Solaris.
Oracle began this in 1998. By 2006 they had their own Oracle Enterprise Linux distribution.
> By 2006 they had their own Oracle Enterprise Linux distribution.
By putting their name on Red Hat’s hard work and reputation.
well, IBM very publicly invested 1Bn USD into supporting Linux on all their hardware with all their software. so db/2 on s390 on Linux, likewise websphere, etc. it gave the customers the promise of one run time environment on anything. and SUSE and shortly later Red Hat provided truly source compatible environments for software vendors. "code once run anywhere", for real. and then IBM and Oracle and Co forced suse and red hat to become binary compatible at the kernel/libc and basic system libs level, so Oracle and all could provide one binary under /opt on any Linux...
and that pulled all other vendors along, HP, Dell, Fujitsu, likewise for software...
and it all started with IBM officially supporting and pushing the hobbyist student project Linux on the holy Grail of enterprise compute, (of 1999/2000): s390
> IBM very publicly invested 1Bn USD into supporting Linux
I remember Avery Brooks (DS9's Captain Sisko) doing a commercial about IBM backing Linux in the year ~2000-ish.
Don’t overlook the early BSD revolution.
4.3BSD was basically designed without any bespoke hardware platform of its own. They commandeered DEC’s big iron, for the most part, to “dual boot” before dual-booting was cool. 386BSD began to enable PC-compatible hardware and really cost-effective “server farms” even before Linus was a twinkle in Finland’s eye.
Moreover, various BSD flavors were empowering admins to breathe new life into legacy hardware, sidestepping and bypassing the proprietary software channels. Linux, on the gripping hand, remained x86-unportable for awhile after BSD (and Xfree86) was running everywhere.
Personally I ran Minix-286 at home; at university we enjoyed a “recreational” VAX11 running not VMS but 4.3BSD.
Flash forward to 1998: from the arid but air-conditioned Sonoran Desert I received gently-loved twinned Apollo 425t systems with memory upgrades; I installed OpenBSD on both, as well as my 486DX100! It was a homogeneous OS environment with heterogenous hardware... and the 486, with Adaptec SCSI & a VLB #9GXE64 Pro, could boot into Windows 98 and run the Cygwin X server, or DOOM or Quake.
There was a golden age when a dude could walk into any surplus yard, grab Big Iron Unix Boxes, take them home and bootstrap NetBSD. On anything. Bonus: BSD originated in USA/Canada, for a trustworthy chain of trust. (Oh Lord, the encryption export technicalities...)
Linus played follow-the-leader for years.
This whole thing is very cool and worth reading.
BUT. I worked at a place that used IBM 360s. We ran stuff for engineers, a lot of Fortran along with assembly code. We had so much stuff going on we could not code up and run things fast enough. The engineer/scientist got frustrated.
Then one day an engineer brought in an Apple II from home and ran the programs on that.
The earth shook. The very ground beneath us moved. Tectonic plates shifted. The world was never the same again! I think it was Visicalc.
Later there were other things. Soul Of A New Machine. The Mac.
I wonder how the compute power of a current high end smart phone compares with and IBM 360? I know the graphics chip is better.
I wonder how the compute power of a current high end smart phone compares with and IBM 360? I know the graphics chip is better.
A current high end smartphone has around 10 billion transistors.
From https://gunkies.org/wiki/IBM_System/360, IBM made 11-12 million SLT modules per year in the late 1960s, with less before that. Each individual SLT module contained a handful of transistors. Therefore, in transistor count alone, a single smartphone has more transistors than IBM produced through the 1960s. And this is before we consider the fact that clock speeds today are much higher than they were in the 1960s.
Your smartphone literally has enough hardware to outcompute the entire world circa 1970.
Isn't it amazing what over 50 years of Moore's Law can do?
My home NAS in the other room could hold about 350 million C64 floppies. I've sometimes wondered how that compares to the world's floppy disk manufacturing capacity in 1982.
I also appreciate that my Internet connection is about 33 million times faster than my first modem. It'd take me over a year to download what I can slurp in about 1 second now, even if I could afford the 7 thousand floppies it'd take to store it.
Progress, yo.
Indeed. I find it interesting to look at the generational outliers on that curve: The Cray-1 wasn’t eclipsed in raw FP compute by a consumer system until the Pentium more than 15 years later.
http://www.roylongbottom.org.uk/Cray%201%20Supercomputer%20P...
Most of the outliers look like, "Someone was willing to spend large amounts of money."
Another outlier was Deep Blue. Estimated cost of about $10 million. Its estimated strength was matched by top end PCs about 9 years later. Your phone today is better than those PCs.
Progress is relentless.
> the entire world circa 1970.
About then was the IBM 360/91 with a 60 nanosecond cycle time. So, that would be a clock speed of
Now we can have clock frequencies of 4 GHz, that is times faster. And we can have 16 cores instead of 1 for times faster. "entire world"?What’s the average IPC of these chips for a reasonable workload?
Early processors were typically 1 or lower. Modern stuff is all superscalar piplined and out of order and can do way more than you’d expect. Not to mention SIMD operations and other technologies. Branch prediction is probably better on the new chips too.
And with more RAM and cache algorithms can be chosen with different tradeoffs for less instructions.
16 cores at 4ghz was a thing like a decade ago - chips today might have the same specs but are definitely far faster.
WOW! IPC, instructions per cycle? Sure, back in those days, usually how many cycles per instruction! The 360/91 was a high end thing, said to cost $13 million. One was at the Navy lab, JHU.APL. As I recall, it could do 1 floating point (32 or 64 bits?) instruction per cycle and sometimes 3 in 2 cycles.
Huh. The article claims at least an order of magnitude more SLT modules than the reference I found. I think it is still quite a bit less than the smartphone, but that makes global compute at least closer.
Still, 55 years of doubling transistors at a given cost every 2 years is about a 190 million fold transistor difference for a given cost. Clock speeds have improved by a factor of 1000 on top of that. Even with performance tradeoffs for battery life in a smartphone, there is no surprise that the phone should have more compute power than the world did in 1970.
If I had to compare computers based on one number it would be the amount of RAM. The 360 had a 24 bit address space which could fit 16MB of RAM although only the largest installations, like the one at NASA, were that big. iPhone 16s have 8GB of RAM so you're talking 512 times the memory capacity, never mind that my desktop PCs are all loaded with 4-8x times that of the phone and you can definitely get a big server with a few TB.
An IBM 360/20 on the small side, however, ranged from 4kB to 32kB which was similar to home computers circa 1980, before it is routine to have a complete 64kB address space.
Where the 360 crushed home computers was in mass storage, 9-track tapes could store 80MB contrasted to floppy disks that stored less than 200kB. Large storage compared to memory meant a lot of focus on external memory algorithms, also there was already a culture of data processing on punched cards that translated to the 360 (e.g. terminals have 80 columns because punched cards had 80 columns)
Where the 360 crushed home computers was in mass storage
Well...sure, you could put bigger storage on a mainframe. It's just money, after all. But you could put a tape drive on a home computer. And bigger disks. And a card reader, for that matter. Where the 360 really crushed the home computer was in aggregate bandwidth, via the Channel architecture. An Apple 2 could just about keep up with a floppy and a display. A 360 could keep up with dozens to hundreds of tapes, disks, card readers, terminals, printers and other things all at the same time.
Large storage compared to memory meant a lot of focus on external memory algorithms
I would agree with that. I would just argue the real mainframe advantage is a whole-system one and not point to a single factor (memory size).
I agree. I did writeups on order of magnitude of RAM and computers over history:
https://saul.pw/mag/memory
https://saul.pw/mag/computer
The IBM 360 is ^4 RAM and the iPhone is ^8 RAM. So the iPhone is ~10,000x more powerful.
Comparing like-for-like (tape storage), you can now buy 45TB tape cartridges. That's a 500,000 times improvement per tape.
Edit: apparently these cartridges actually are 18TB, 45TB is "compressed" capacity. Still though, terrible marketing aside it's still factor of 225,000.
The 360 had 24-bit addressing, for a maximum of 16 megabytes.
The 6502 in the Apple could address 64k of RAM. Any class of problem requiring more memory would need a real machine.
As far as a personal machine with comparable capability, RISC brought that to the market with the first MIPS R2000 in 1985.
https://en.wikipedia.org/wiki/MIPS_architecture
The Motorola 68000, introduced in 1979, had 24 address lines. The Intel 80286, introduced in 1982, also had 24 address lines.
Well, the VAX was there before any of these, but I wouldn't call that a "personal machine."
I suppose the argument could be made that the 68000 was first, as both it and MIPS ended up in gaming consoles (Sega Genesis vs. Sony PS2 and Nintendo 64).
However, MIPS eventually scaled to 64-bit, was well-known and heavily exploited in supercomputing applications, and was used to produce the film Jurassic Park. The 68000 had a far dimmer future.
Yes, the x86 line did supplant them all, but only with AMD's help. Had Itanium been Intel's final answer, MIPS might be much stronger today.
>BUT. I worked at a place that used IBM 360s...Then one day an engineer brought in an Apple II from home and ran the programs on that.
The 360 was introduced in 1964. The 370 was introduced in 1970. The 3033 was introduced in 1977. The Apple 2 was introduced in 1977. So, yeah, if you were still using 360s contemporary with an Apple 2, no wonder the engineers were frustrated.
Lots of organizations run those computers for very long times. It was not unusual for a medium-sized company, a factory or some local government to be running 10 to 15 years hardware.
A $50 smartphone is many orders of magnitude faster.
The most powerful 360/91 was roughly equivalent to a 20MHz 486 from the early 90s.
Mainframes had much more powerful distributed IO for multiple hard drives, tape systems and such.
But the CPUs were really not all that powerful at all.
Many people wildly underestimate just how insanely fast and power-efficient today's commodity computing is compared to high-end supercomputing from earlier decades.
A Raspberry Pi destroys any supercomputer earlier than around 1990, and gives some later models a run for their money.
An Apple S7 watch processor is maybe 25X faster than a Pi 5.
And so on.
Never mind a high-end or even low-end smartphone, I think a Raspberry Pi would absolutely dominate these old machines.
> I know the graphics chip is better.
Graphics? We used these machines with 9600 baud serial terminals.
I am not sure about the 360’s terminals, but some terminals could display graphics via sixels. Konsole and xterm are capable of showing them in the present day if you run a terminal copy of word perfect.
How many years old was the s/260 at this point? If it was really long in tooth then I wouldn't be surprised.
Alan Kay has promulgated many famous truths about computer science - one of them being that among all fields of study, it has the least regard for the people and discoveries that brought it to where it is today. Maybe it's just my own sense of history as I move into my 4th and likely last decade of working with computers, but I find this to be both true and lamentable.
This was a great article - thanks for sharing!
One example of this was the concept of virtual memory, which was invented by Burroughs, not by IBM.
> as I move into my 4th and likely last decade of working with computers
Don't despair--I am in my sixth and still program every day.
Yeah, programming is rewarding. I just got tapped for CTO and basically fell into a pit of depression.
How many of the people who made the steam engine possible do we remember? James Watt of course, but many many people were making contributions in material science, needed to make them useful. Not to mention many advances in values. No doubt lots of other areas as well, but I'm no expert in the steam engine.
Not sure what you mean by this - it's not as if steam engines are an extensive technology today, and certainly no university is teaching "steam science", while nearly every school is teaching "computer science".
Perhaps this is just the attitude that drives Mr. Kay's point home - do individuals who are interested in CS have little value for who and what has come before them?
To be fair, everybody who takes a thermodynamics course owes 90% of it to the 'steam science' pioneers. Understanding what determines and limits the efficiency of heat engines was as big a deal in its day as the WWW is in ours, but unlike our own era, a lot of brand-new science and math had to be discovered by those engineers.
Steam tech is much, much more interesting than it appears at first.
Sure they do, it's just called fluid dynamics and thermodynamics. Enough to fill up about 1/3 of a mechanical engineering degree, if you're really into it (most aren't).
Not that there's a lot of historical context to things as far as which people did what - most of that sort live on in names of techniques and methods (Rankine cycle, de Laval turbine, Carnot efficiency, etc.)
I studied Materials Engineering. Similar experience.
Carnot, Thompson, Clausius, Gibbs, Rankine, Boltzman etc all made big historical contributions to modern understanding of Thermodynamics.
And for Fluid Dynamics: Euler, Bernoulli, Mach, Stokes and so on.
And if you are looking for someone more modern I'd say Ergun (Packed bed's, Fluidized Bed Reactors etc).
All builds upon "steam science"
The successor IBM Mainframes are still alive... for the time being.
https://www.redbooks.ibm.com/redbooks/pdfs/sg248329.pdf
oh, they'll stay around for another while.
they also moved on three more CPU generations since that redbook, to z17.
I think it's Linux on Z that makes it sexy and keeps it young, in addition to a number of crazy features, like a hypervisor that can share CPUs between tenants, and a hardware that support live migration of running processes between sites (via fibre optic interconnect) and the option to hot swap any parts on a running machine.
It's doing a number of things in hardware and hypervisor that need lots of brain power to emulate on commodity hardware.
_and_ it's designed for throughput, from grounds up.
Depending on your workload there may be very good economical reasons to consider a mainframe instead of a number of rack-frames.
>Depending on your workload there may be very good economical reasons to consider a mainframe instead of a number of rack-frames.
For legacy companies yes but it would be very hard for new YC companies or existing non-mainframe companies to create a spreadsheet showing how buying a new IBM Z mainframe would cost less than the latest commodity x86 or ARM servers in the cloud or on-premise.
The IBM pricing for mainframes makes sense for legacy companies like banks and airlines with a million lines of old COBOL code that want to keep it all running with the latest chip technology. (The mainframes from a few years ago are coming off the lease and they need to upgrade to whatever new mainframe IBM is offering and sign another lease & service contract.) So, IBM mainframe prices are very expensive -- but legacy companies will pay it because migrating the code away from mainframes can be even more expensive.
It's similar to expensive enterprise pricing of Oracle, Embarcadero Delphi, Broadcom etc that takes advantage of existing customers already locked into their products. Virtually no new tech startup with a greenfield project is going to pay Delphi $1599-per-seat for each of their developers. Only existing customers stuck with their investment in Delphi code are going to pay that. (https://www.embarcadero.com/app-development-tools-store/delp...)
But some companies do endure the costs of migration to get out from IBM lock-in. There are lots of case studies of companies shifting their workload from mainframes to AWS/GCP/Azure. I can't think of a notable company that did the reverse. Even a mainframe hardware vendor like Fujitsu quit making mainframes and shifted to x86 running an emulation of their mainframe os.
Yes, IBM mainframe can run other workloads besides COBOL like Java and C/C++ but no company that's not already using mainframes would buy & deploy to IBM's Z hardware for that purpose.
Building a fast reliable fault tolerant system is easier on mainframes than the cloud you're familiar with.
Imagine having transactions ACROSS services. Do you know how much bullshit and over engineering that gets rid of? A lot.
in a nutshell a mainframe is a cloud in a box for high throughput workloads which need crypto and tpu accelerators.
mainframe pricing usually is not by pound of iron but per cpu cycle. unless you say nah I'm buying the thing, not just cycles. soyou have a choice of cloud pricing or hardware pricing.
for significant pure Linux workloads that need an own on premise cloud the TCO pricing is surprisingly competitive with any home grown solution.
even if you don't _need_ an own on premise cloud, AWS and similar donate come for free and there may be a break even there, too.
that said, legacy host software, Delphi, cics, Oracle, DB/2, cobol etc, you named it, yes that's a different story, with all the extra software licensing.
but a pure Linux mainframe is surprisingly competitive not just in compute and throughput but also in pricing.
plus you get quite some high availability in silicon. think ECC on the ALU, hot stand by spare CPU, multipath everything, if your business depends on uptime your system architecture becomes much simpler on highly dependable hardware.
so that spreadsheet compares own people and software construction vs IBM tax in some columns.
lol I start sounding like an IBM sales person https://www.ibm.com/products/integrated-facility-for-linux
I just did Linux on Z for a while and I loved it, so please bear my enthusiasm :-D
>but a pure Linux mainframe is surprisingly competitive not just in compute and throughput but also in pricing.
It's not competitive when you consider what long-time IBM mainframe customers actually do. E.g. SABRE airline and travel reservation system was one of the first IBM mainframe customers in 1960 with the IBM 7090 and then upgraded to System 360 and then the newer Z mainframes. SABRE's multi-decade experience with IBM mainframes with mission-critical business applications means they are one of the world's foremost experts on its capabilities & costs that's not biased by any IBM marketing or sales pitches.
Even with all that in-house experience, SABRE still chose to gradually migrate off of IBM mainframes to less expensive tech stacks. Some have touted IBM's TPF (Transaction Processing Facility) on the mainframe as compelling technology but that still didn't dissuade SABRE in ~2001 when they migrated the airfare pricing application to Tandem (Compaq/HP) NonStop servers running UNIX. (https://www.computerworld.com/article/1339621/has-mainframe-...)
They then started a 10+ year effort to migrate more mainframe workloads to Google Cloud. E.g. from https://www.sabre.com/insights/a-journey-to-tackle-legacy-co... :
> We moved 93% of compute capacity from physical data centers to the public cloud, resulting in a 50% decrease in our compute costs.
> We migrated more than 120 million bookings from a mainframe-based system to one using Google Cloud’s Spanner database, without impacting customer operations.
JP Morgan Bank is another example of migrating from IBM mainframes to cloud. If anyone out there truly thinks that running a new greenfield Linux workload will be be cheaper or even cost-competitive on a new IBM Z mainframe, just pause and consider if you truly know something about IBM mainframes' OpEx that multi-decade IBM customers like SABRE and JP Morgan don't already know.
Why would any new customers in 2025 willingly buy into IBM Z mainframes if they see existing customers spending billions trying trying to move off of them?
I’ve had to budget a line of business app that runs on both z/OS and AWS. Reliability for both hit an asymptote somewhere around 2019. The opex price crossover happened somewhere around the same time, depending on the customer.
Nearly every installation site and their internal support director agrees that the z/OS installations are far less expensive to support, simply because the minimum level of experience for a z/OS engineer is about a magnitude more than a cloud engineer.
So a more experienced engineer with a relatively rare skillset is less expensive? I think i'm missing something.
> Tandem (Compaq/HP) NonStop servers running UNIX
Nitpick: The OS these machines run is called Guardian. It does have a POSIX/Unixy subsystem/compatibility system called Open System Services.
It’s a risk issue. 5 year high risk projects aren’t appealing to CIOs with an average tenure around 18-36 months. Even if it works, why should the next asshole get the credit?
I think the point is that IBM’s market is shrinking, and they can’t acquire new customers. They will eventually need to stop making mainframes because there will be a crossover between the cost for new mainframes for remaining customers vs transition to commodity hardware cost.
Virtually no new tech startup with a greenfield project is going to pay Delphi $1599-per-seat for each of their developers. Only existing customers stuck with their investment in Delphi code are going to pay that.
I agree with this, and all your other reasons why mainframes will remain legacy platforms.
But man, how crazy is it that an industry that is 100% productivity driven and (until AI data centers, at least) labor-cost-constrained would snub its nose at paying a fraction of a percent of those developers’ salaries to put good tools in their hands.
All those times I've seen managers pooh-pooh RAM upgrades for machines used by people whose salaries might be 250-500x the machine...
I suspect the main reason isn't just strictly economical. If you are Google or some such you can probably compensate by building smart software around commodity hardware, but most companies simply can't. Even if they have boatloads of money (banking, insurance) and can hire expensive talent, they simply can't successfully complete such an undertaking because they don't have it in their DNA, and management isn't incentivised to take on such a risky project.
In this case they will just use a mainframe, even it isn't cheaper in the long run.
Thing is Google does not use commodity hardware for their DCs as far as I can tell. They got famous for that back in the early 2000s but I think they abandoned that approach a long time ago.
They may design their own hardware, but their approach to scaling and fault tolerance is still the same: not a low number of fast and very expensive enterprise grade hardware that is unlikely to fail, but a huge fleet of servers that scale horizontally and that can tolerate the loss of a machine.
Which is the Mainframe vs commodity server dichotomy.
> I think it's Linux on Z that makes it sexy and keeps it young
They feel fantastic when running Linux, but, if you don't need all the reliability features that come with the platform, commodity hardware might be a better choice for the kind of workload that has evolved on Linux.
> Depending on your workload there may be very good economical reasons to consider a mainframe instead of a number of rack-frames.
Absolutely - it makes a lot of the administrative toil disappear. I know clusters are sexy, but getting the job done is always better.
Other than IBM’s absurdly high pricing, they’re cheaper to run in almost every way than x86 machines (including cloud). I haven’t done the math to compare with aarch64/ARM.
But most people don’t want to deal with the hassle of dealing with IBM.
Do you have resources that provide info on companies using Linux on Z and the benefits of this verses commodity hardware? I used to work for a Mainframe ISV but the majority of our software ran on z/OS. I only saw customers using Linux on Z to begrudgingly run software that wouldn't efficiently run on z/OS, mainly Java applications when customers didn't want to deal with the complexity of specialty engines. I realize because our software focused on z/OS I had limited visibility into the full operations at our customers.
the advantage comes with the full package, operations and all.
you don't have racks with blades but one box or two, that you upgrade every few years and other than that your hardware side is covered.
rewiring networks, reattaching storage etc all remotely, CLI, and most importantly you only pay what you use.
you need one guy or a consultancy for the initial etc up and for fancy Config changes but once it's essentially set up you simply have a large Linux data centre and do Linux stuff.
oh and you can hot plug additional physical CPUs into a running VM and pull it out and reassign when it's not needed, likewise RAM. that's somewhat difficult with commodity hardware.
and there _are_ companies that value this and choose Linux on Z as a pure Linux deployment.
but you have a point. if nobody in the building knows this, nobody's gonna call IBM and ask for a quote. it's simply not on anybody's radar.
> Depending on your workload there may be very good economical reasons to consider a mainframe instead of a number of rack-frames.
This may be true, but because there's basically no on ramp to running on a mainframe, there's no way anybody is going to try it unless they're already on a mainframe. Or maybe unless they really need something that only a mainframe can provide. But most companies can live with some downtime, and once you can live with some downtime, you have options for migration between sites, and options for migrating loads so you can swap parts on a stopped machine. Splurging on network infrastructure with multi-chasis redundancy is an easier step to take to get to a more reliable system than building against a totally different system architecture.
> This may be true, but because there's basically no on ramp to running on a mainframe
You can get a partition of IBM Z to run in the cloud. The cost is about $5/hr for the smallest configuration.
> Splurging on network infrastructure with multi-chasis redundancy is an easier step to take to get to a more reliable system than building against a totally different system architecture.
Yes and no. If you truly need that redundancy than the mainframe is going to provide a much better version of it. SYSPLEXs and LPARs are some insanely powerful technologies.
A mainframe is the biggest single system image you can get commercially. It's the easiest, most reliable way to scale a classical transactional workload.
> A mainframe is the biggest single system image you can get commercially
It depends. As we have seen the other day, HPE has a machine with more than 1024 logical cores, and they have machines available to order that can grow up to 16 sockets and 960 cores on a single image of up to 32TB of RAM. Their Superdome Flex goes up to 896 cores and 48TB of RAM.
I believe IBM's POWER line also has machines with more memory and more processing power, but, of course, that's not the whole story with mainframes. You count CPUs that run application code, but there are loads of other computers in there doing a lot of heavy-lifting so that the CPUs can keep running application code at 100% capacity with zero performance impact.
> It's the easiest, most reliable way to scale a classical transactional workload.
And that's where they really excel. Nobody is going to buy a z17 to do weather models or AI training.
SGI’s UV 2000 could scale to 4096 logical cores and 64TB of RAM around 13 years ago. The current 4096 core limit in Linux is from that.
My partner makes a living writing z/OS assembly language, has been for many years now. The platform is still going strong as a business. The main problem they face is all the folks who know how to program these things are retiring (or dropping dead at their keypunches.) It's very hard to convince new people to learn how to operate these systems.
For your partner's sake I hope you're right but is z/OS as a platform actually continuing to grow, or are they just having a hard time filling seats because it's hard to see a long and profitable future working on (what some might call) "legacy" systems?
When I was growing up (decades ago, mind), my dad kept trying to convince me to get into machining. Lathes, mills, tool and die making, etc. In his line of work, he saw lots of machining companies basically paying all education and training expenses for new hires because their experienced old timers were retiring faster than they could be replaced. (He also thought computers were a fad...) I'm sure it was a good opportunity at the time. But nearly all of those companies eventually closed up because offshore manual labor was and still is way cheaper. If I'd had taken his advice, I'm pretty sure I would have had to reboot into another career at least once by this point.
Interesting.
What sort of applications does your partner work on?
He does system level stuff, enhancements to IBM's z/OS. A lot of their customers are big financial institutions, banks and the like that use MVS for transaction processing. His software augments the operating system and isn't application specific.
The IBM Centennial Film has a short interview with Fred Brooks about System/360: https://youtu.be/VQ0PBve6Alk?t=84
Set to some nice Philip Glass music to boot.
The reason the tape drives are in those tall enclosures are the vertical channels below the tape reels. That was for slack in the tape, there was a loop of tape hanging in each of the channels, so that tape reads and writes could be stopped and started faster than the heavy tape reels could stop and start.
This is super interesting to me, thanks for that. Are there any other hidden but well-known things like that?
My sister worked at IBM and one of my favorite stories is when Lotus tried to pressure IBM to spend millions on licensing, a few engineers went off and built their own spreadsheet application and IBM told Lotus to piss off.
To add to this: they had $750 million in 1963 dollars, in parts and no shipping computers; inventory control was so bad that they had to have guys with clipboards to physically go into the warehouse and count parts.
They announced it and started getting a huge number of orders; IBM hired 1000 people a month and kept up that pace of hiring for 5 years.
I liked the Mad Men plot about the computer arriving in the office. Everybody was trying to decide how to react to it.
The well known book "The Mythical Man Month" is in large part based on the author's experience as one of the top people on the System 360 project, and what went wrong during the effort.
As an ex-IBMer, I miss the IBM of old. So much innovation. Now they are just a consulting company. So sad to see it go that way.
Indeed. Their current goal as communicated to shareholders is literally to move all engineering offshore.
And this is all before integrated circuits, so the circuits are still very large, consisting of many circuits on boards mounted on a backplane.
https://en.wikipedia.org/wiki/IBM_System/360#Basic_hardware_...
https://en.wikipedia.org/wiki/Solid_Logic_Technology
Thomas Watson, Jr.'s A Business and Its Beliefs was published in 1963 and makes no allusion to the S/360 work. It makes for curious reading today, for unrelated reasons.
i have also found these to be interesting, kind of selection/ analysis/ visualisation over memoirs of Lou Gerstner (part 2 is around s/360):
https://juliusgamanyi.com/2018/12/28/wardley-maps-an-illustr...
https://juliusgamanyi.com/2019/06/18/wardley-maps-an-illustr...
https://juliusgamanyi.com/2020/06/25/wardley-maps-illustrate...
Now, reading the article, this "[rivalry].. So intense was it that sometimes it seemed to exceed the rivalry with external competitors.” reminded me of something old about Motorola.. where rivalry went to the need to reverse-engineering other depts' chips via 3rd party acquiring them..
www.chicagomag.com/Chicago-Magazine/September-2014/What-Happened-to-Motorola/
z boxes use a flavor of VM to run all the LPARS and allocate memory and devices. z/OS, z/VM and Linux all run as VMs.
Then there's CMS which runs under VM; theoretically it could run as an LPAR, but I've not seen that as running DIAGNOSE (VM system call) to the LPAR hypervisor could be disruptive. It would be interesting to drop DIAGNOSE into a z/OS environment, but I suspect it would be intercepted.
I much prefer z/VM to z/OS as a development environment. At one shop, I developed products under VM for deployment under both VM and MVS.
Many early S/360 installations ran 7070 and, I guess, 1401 emulators.
Eventually with VM, the SIE (Start Interpretive Execution) instruction appeared. A form is running LPARs.
Fascinating look at the challenges and risks IBM took on with the System/360. Betting the company on a compatible mainframe family was visionary but nearly disastrous. It's a testament to the importance of strong technical leadership, teamwork and perseverance to bring revolutionary products to market.
It was a business decision driven by Tom Watson Jr. after listening to a lot of customer feedback. See "Father, Son, and Co." https://www.amazon.com/Father-Son-Co-Life-Beyond/dp/05533808... his autobiography of his years at IBM, and beyond. The 360 project figures prominently.
This was some great read
Your comment was reason enough for me to read it, 8/10
[dead]