Going back to the hardware that everyone likes to focus on, it's less radically different from normal servers today than it was historically. The mainframe today is a 19 inch rack like any other. By that i mean it is not only a 19 inch rack like your x64/ARM servers are but also the same power density (32 or 64 amp racks), cooling requirements etc.
The most interesting bit is the software, not the hardware. There are cool hardware aspects too - but focus on them and you miss the real reason these things are popular in certain environments.
E.g. how many variants of IRC have we had now? Usenet? VMs?
Why pay for disk and compute access when you can have a workstation! Why have limited access to the system when you can have your own! Was the vibe.
It is amusing/sad that in the AWS world we're right back to basically mainframes. Centrally hosted massive compute that you don't really have full control or access and have to pay for use time.
I wonder when the next swing back to personal computing arrives?
The Main Frame of yore was ... one of the 19 inch racks the computer was made out of (the main one, typically with the ALU and registers in it). And those racks were used because that was how phone systems were built (phone systems had a lot more repeated / regular structure than something like a computer, though of course everything has converged). The "frame" nomenclature came from the phone system too.
So "normal servers today" got the rack from the mainframe, the mainframe didn't adopt it because of how datacenters were built. All the familiar stuff (raised floors, chillers, backup power, fire suppression, controlled access doors and so on) come from the mainframe world.
The processor checkpoints state, and if an error is detected it can be rolled back and the checkpoint moved to another physical processor and re-started transparently to software. Stores are tracked all the way down to "RAID memory" (actually called RAIM), whereas in other CPUs they get punted off at the L1 cache. Practically every component and connection is redundant. There are stories of mainframe drawers being hauled to particle accelerators and the beam switched on while they're running. Quite amazing machines.
Not to say that has more value than the software (I don't know one way or the other), but the hardware is no gimmick.
Hot plug CPUs, memory modules, and DASDs. All survive the failure scenario gracefully.
Good luck trying to do that on a rack of x86 servers.
I think as in most engineering things. They do a different trade-off and cater to a different niche while x86 servers are the mass market consumables that most workloads -should- be using. The mainframe CPUs go for the widest IO capabilities, insane cache sizes and hardware offload because that’s what their target audience(banks, insurance companies, airline ticket systems) need.
Their parallel sysplex clustering solution is an engineering marvel but also tightly coupled to their hardware.
In some ways, the IBM mainframe is the Apple of niche critical enterprise computing. They are also the ancestor of cloud computing in paving the way for “pay per use” cost models and multi tenancy.
It is never technical or pratical reasons, always economic reasons. To use contemporary vocabulary, you "just" need to replicate a "multi tenant HA cloud environment" to migrate from a mainframe at great cost.
> And now we are in a situation where their long held beliefs have become true because nobody is around that understands how or why the software works the way it does.
Statistically unlikely, most of the business software that goes onto said mainframe is in fact very simple and straightforward and can be easly ported out, however, the real deal is all the integration and high availability logic built-in into "the mainframe platform". You're not porting that out without replicating said "multi tenant HA cloud environment" at great cost.
Most of these kinds of systems have decades of codified knowledge that applies the legal requirements of many disparate jurisdictions in these systems. Laws vary from city to city, county to county and state to state, and that's only for the US. Some of these systems implement code that applies legal requirements for dozens of nations.
In general, you're going to have to spend at least a year just to document the existing system. Another six months to a year generating test cases and scripts for validation. And that's before even starting to build the new system. And that is ALL optimistic, assuming everything goes right.
I had to once write a relatively simple application for "vacation bidding" where in employees will get a position to request certain weeks off during the year. This was a legal requirement and happened to involve the company, two other companies that had been merged in and three unions. Each with different rules regarding how seniority is calculated. The contractual specifics were over two thousand pages long. That's just one very small piece of software in one of these very large companies. It took the better part of a year to implement. Now imagine taking that a couple decades later after it's evolved and migrating to an entirely new platform and paradigm. Now imagine the cost to do that.
I was part of a 4 person team that knocked this out in under a year. 1,000's of mainframe programs running w/o change (at the time) on Unix. This was in the 90s.
When folks have replaced significant enough chunks with other apps, or otherwise made the prospect less daunting, then it may happen. It just comes down to cost and risk management.
The hardware might be whiz-bang but the legacy applications are slow, outdated, and extremely hampered in functionality.
In my state, the birth records system is electronic, and so is our RMV. But in order to get a RealID, I had to get a paper copy printed out to bring to the RMV because they can not, or will not, integrate the two systems. Meanwhile other countries have things like electronic ID cards with personal certs so you can electronically sign documents and identify yourself.
The whole thing is a giant puff piece for IBM, reading like a sales presentation transcript.
https://learn.microsoft.com/en-us/dotnet/csharp/programming-...
https://hackage.haskell.org/package/postgresql-typed-0.6.2.4...
Vertical integration of the business into one magic box is a perpetual dream of mine. Bonus points if I can yell at exactly one vendor if anything goes wrong.
AFAIK Fujitsu still manufacture mainframes
All the mainframe OSes I know of except IBM's run under software emulation nowadays.
I think the main things missing is how much IBM really brings to the table here.
> If one crashes or has to go down for maintenance, the other partitions are unaffected.
Effectively, IBM often does that for you. The machine detects an issue, and calls IBM, who sends someone out (in my day it was immediately), and they fix it. Then it's fixed and they leave and most of your staff has no idea they were there at all.
Plus, there's not enough that can be said about using a dedicated stack of hardware and software owned by one company. If there's an issue, it's IBM's. They are the ones who need to fix it. No trying to get HP vs Microsoft to agree to take the blame (which can take literal weeks). Just call IBM, and they take care of it. (In theory)
The ways I've heard that explained sound exhausting. Paying anyone who you can say, "your machine broke come fix it" and they actually do, is probably worth the money. Right now Cloud providers and IBM are the only ones really providing that service. I suspect history will say that people were not running to the Cloud so much as running away from bullshit hardware vendors.
That being said usually I am the one replacing that part on my own infrastructure which is usually a 30 minute drive an hour to maybe 3 of my time
advantage - one throat to choke
disadvantage - they've got you by the balls when it comes time to pay the licensing and maintenance fees
We had a machine in there that by the time I left was running nonstop for 10 years. I was their only IT person for 5 of those years, and I basically visited them a few times a year to work on MSAccess reports, and never touched the server (I may have never even logged into it!). It just chugged along running their entire business with no maintenance.
The hardware and software are certainly impressive but does anyone use a mainframe for a new project and not just upgrading or expanding an existing system?
I'm in integrated circuit design and we have compute clusters with thousands of CPUs. For some jobs we use a single machine with 128 CPUs and over 2TB RAM. Some steps get split over 30 machines in parallel. All of this EDA / chip design software migrated from Sun and HP workstations in the 1980's and 90's to Linux x86 in the 2000's. I think some of it ran on mainframes in the 70's but does anyone use mainframes for scientific style calculations or is it just financial transaction / database kind of stuff?
I know of two companies, and at least one still use it, had several summer jobs there. They make sheet metal rolls by flattening out train cart sized hunks of steel, and while the mainframe system didn't run the machines (operators and PLC handled that) it kept track of everything, inventory, logistics and planning. I used it to plan rail shipments, where to put each roll of sheet metal on a train and loaded them up.
So on one end mainframes, on the other ends software written for DOS and Windows 3.x still being used in (at the time the 2010s) to keep critical infrastructure for manufacturing running.
40 years here. Although in theory I've used a mainframe in college, but it wasn't IBM (Burroughs) and just seemed like "a computer" at the time. I also worked a bit on a terminal emulator for ICL mainframes, so probably at least logged in. So 40 years of saying "I wonder if the mainframe people already have a solution to this?"
Probably mainframes haven't been much used for HPC since the transition to Cray in the 70s.
Very wrong. Five nines is five minutes and 13 seconds of cumulative downtime in a year[0].
Three seconds of downtime in a year is seven nines[1].
I suspect that for most organizations that use mainframes today, there are so many integration points and so much data is involved that the economics that drove a lot of early-on timesharing no longer apply.
This can be very attractive compared to the never ending OpEx for running cloud computing.
It's that ultra short term results focus that the stock market demands these days, sadly.
Maybe a few really big organizations would buy them outright.
I think the first sentence is 100% correct, but the second one not so much: current desktops and servers (not to mention laptops, tablets, smartphones etc. etc.) evolved from the first microcomputers introduced in the 1970s with the idea of having a computer (albeit initially a not very capable one) that anyone could afford. These then quickly evolved during the 1980s and 1990s to cover most of the applications for which you would have needed a mainframe a few years earlier.
Each person has a box in which they are essentially the sole tenant, versus a big box that has to have a bunch of sophistication to handle multitenancy.
I'm honestly surprised that a bank would agree to run anything even remotely serious on someone else's infrastructure.
In the end, I guess it's all about the money ... and that includes the money it takes to find and train mainframe devs.
Source: spent a significant part of my career in fintech.
I don't know if they ever realized even dedicated fiber links were software switched by that time so it was easy to misclick and send an entire fiber stream to their competitor too :)
I've heard a lot of largely clueless people who weren't aware of the differences between the zeries and pseries say something like this, but its generally been entirely false (especially 15-30 years ago which overlaps with some time I myself spent at IBM). Given the rest of the article I wouldn't presume the author is in this category.
So has something changed? or is the implication stretching the truth? I mean I guess you could strip a POWER core down so it only runs s390 microcode/etc, but that likely won't actually yield a performant machine and the process of evolving it would likely fundamentally change the microarch of whatever RISCish core they started with.
I mean they are entirely different Arches, in the past utilizing entirely different microarches. I can see some sharing of a RTL for maybe a vector unit, or cache structure, or a group doing layout, but that doesn't make the zeries processors any more derivative of POWER than Itanium was derivative of x86, etc.
PS: the bit about zos partitions supporting linux seems like a bit of confusion too, earlier its correct about the LPARs being capable of running linux directly, but ZOS isn't providing the lpar functionality, and is generally just another guest alongside linux, ztpf, and various other more esoteric "OSs" that can run natively. There is a unix system services in zos but that isn't a linux kernel/etc.
"The z10 processor was co-developed with and shares many design traits with the POWER6 processor, such as fabrication technology, logic design, execution unit, floating-point units, bus technology (GX bus) and pipeline design style, i.e., a high frequency, low latency, deep (14 stages in the z10), in-order pipeline.
However, the processors are quite dissimilar in other respects, such as cache hierarchy and coherency, SMP topology and protocol, and chip organization. The different ISAs result in very different cores – there are 894 unique z10 instructions, 75% of which are implemented entirely in hardware. The z/Architecture is a CISC architecture, backwards compatible to the IBM System/360 architecture from the 1960s. "[2] For the POWER
[0] https://www.realworldtech.com/eclipz/ [1] https://news.ycombinator.com/item?id=18494225 [2] https://en.wikipedia.org/wiki/IBM_z10
I thought the IBM Z Architecture was the CISC based System 360 / 390 architecture from the 1960's. At least that is what I remember my one friend who has some mainframe experience was telling me.
Sometimes that is how one goes big, by taking care of stuff no one is interested into doing, and when there is enough money in the bank, go after everything else.
So, yup, JCL still works! An 3270 series video terminals with 24 lines of 80 characters each driven with CICS (customer information control system or some such) is still used.
But I didn't see that
(1) Rexx, often a good replacement for JCL,
(2) XEDIT, and the PC version KEDIT, my favorite text editor,
(3) and VM/370, an impressive virtual machine supervisor, upgraded from the original CP/67 for the IBM 360/67 mainframe
are still supported and used. I would be shocked if they were not still supported and also still used, especially for development and analytical computing tasks.
Then in Memphis, one evening used the code to develop a schedule for all planned 33 airplanes for all planned 90 US cities. The next day two representatives of BoD member and crucial investor General Dynamics went over the schedule carefully and announced to the BoD that "it is a little tight in a few places but it's flyable". Until that schedule, due to concerns of some BoD members, scheduling had been a show stopper. But with the schedule the BoD was pleased, crucial funding, equity and also counting loans on the planes, etc., $55+ million, was enabled, and FedEx was saved until the next such BoD crisis.
I solved the next such BoD crisis with the differential equation
y'(t) = k y(t) (b - y(t))
and for this one, for the computing for the data to draw a graph of the solution, used my new HP calculator I'd paid $400 for! There the BoD wanted some revenue projections.
NCSS was expensive, but I enjoyed using it AND PL/I! It didn't use 3270 communications and, instead, used asynchronous bits on a phone line and a portable terminal with heat sensitive paper in rolls. The terminal was from Execuport and supposed to be portable. Actually, it was delicate!
It is just staggering how far computing has come since then! Hardware, operating system software, APIs, user interfaces, communications, YES, but applied math, algorithms, and programming languages, not as much and, thus, seem more fundamental!!!!
As someone stated in another comment, the software is the impressive part.
Like the article mentioned, migration was a Herculean task done over a period of years, with a good chance it wouldn't succeed. I worked many 70 hour weeks, I had to drive to the factory at 2AM some days to monitor jobs because only certain people had remote access. Floating point and text encoding was different between the systems, decades of legacy engineering and manufacturing data and code (having cost hundreds of millions of dollars to produce) had to be translated and verified. There was a rivalry with the mainframe group who wanted it to see it fail, reluctant programmers, engineers, and line workers. On and on and on...we had to apply start-up levels of creativity and ingenuity while working in an MegaAeroCorp bureaucratic atmosphere.
Ultimately, the project was a success, although the system soon moved to PC-based desktops as graphics cards became more powerful. I got a company award from my internal engineering customers. Shortly after the dust settled, I got called into a secretive meeting with my boss and the department head, expecting a promotion and a raise, or at least an "Attaboy!" No, I was reprimanded by an HR rep with a formal note in my records about my attitude ("You risked everything by cowboying!"). I was admonished for having the gall to take a couple of sick days during the ordeal (my coworkers were concerned when they found me passed out at my workstation, my boss warned me after my time-off "If you are sick be sick" and called me a filthy name.) I was put on double secret probation.
Our whole department was eventually outsourced, and I ended my tenure there by being escorted by security to the door and told not to let it hit me in the backside. I guess I should have joined the mainframe group on the business side, in retrospect, they are still around grinding out profit statements. It was a challenge to get rid of a mainframe, maybe more so than eliminating our entire engineering support team.
There are efforts made to make sure code doesn't break and migrations are put in place.
Sadly only Microsoft and a few others share this attitude, and its likely why these companies and their products will be around forever.
Since the introduction of Windows 10, this is no longer true. For example, games that supported Microsoft's "Games for Windows – Live" often do not not work out of the box anymore, as required DLLs are no longer installed. And on the 2017 Microsoft Answers thread about what to do to work around this[0], users are reporting the steps no longer work.
[0]: https://answers.microsoft.com/en-us/windows/forum/all/guide-...
I still feel interested though. I'm aware of the current state of chaos on mainframe development, but honestly, I don't think that the current web/mobile situation is much better and, besides, I personally hate them really bad.
Let's say someone knocked on my door tomorrow and said "We're looking for someone with any experience at all with JCL on IBM mainframes. We'll pay a million dollars a year for a 10-year guaranteed contract. Are you that guy?"
I would say "Nope. Sorry. I'm a plumber. I don't know nuthin' about computers."
(And then they would say "Ha! GOTCHA! How'd you know we were talking about computers? Now take your million-dollar check and watch your head as you get into this nice black helicopter.")
That said: what the business types like is the belief, whether it's true or not, that when you call IBM for service they're there before you hang up the phone.
Also, a long time ago at Oracle, I sat in probably the most boring meeting of my life: a group called MOSES, composed of sysadmins for Unix. Their complaint was that, supposedly, all mainframe sysadmins did things the exact same way, so if you hired a new one, there was no training. Whereas in Unix, everyone did things differently, so a new hire couldn't be productive right away.
What distinguished mainframes from minicomputers back then wasn't their awesome processing power, or their resilience; it was their huge IO capacity. They could handle hundreds of storage devices, and hundreds of thousands of terminals. At least, that's how I was told it; I never worked on mainframes.
Nowadays a single connection to the internet can connect you to a similar number of "terminals", and storage is also accessed over a network. So the advantages touted by the author are quite different from what they used to be; IO nowadays isn't the issue it was back then.
Backward compatibility helps - you can still run code for the IBM 1401 on these machines if you need to. When they came up with System 360, they effectively crystalized software development... taking what used to be a forced march to new hardware every few years as you got a new, faster, incompatible machine, and were rewriting the code for the better faster hardware.... and just FROZE that stream of development, which is why Y2K really happened.
But even that's not the real reason IBM mainframes have stuck around so long... it's the same reason Virtualization and Containers took off.... they give no default access to files or disks, the administrator has to plan out which disks and other resources a Job, (or Runtime, VM, or container) will access. (Example, the DD statement of JCL[1])
This has the effect of being a very course grained capability object system.[2]
The default access to everything on a Windows/Unix/Linux system just doesn't work in the modern era. It is because side effects can be strictly controlled, that Mainframes and later VMs and Containers have so much value.
-- a small rant:
It's 2023... consider the humble AC wall outlet, you can plug almost anything into it, and the circuit breaker or fuse will prevent bad things from happening to your wiring, house, etc.
Why can't we protect against a rogue device plugged into a USB port? Why can't we just run any program we please, like we can plug in a lamp we bought at a garage sale, without risking everything?
--
[1] https://www.ibm.com/docs/en/zos-basic-skills?topic=concepts-...
Any normal person would prefer to program in S/370 assembly than be forced to use EJB 2.0 Entity Beans.
tldr: This awesome professor has an amazing track record of getting seemingly "average joes" trained up for mainframe programming. Because of how uncool this process is perceived by the average SV developer, it's literally shunted off into the dark recesses of the world, despite it being an awesome jobs platform.
