3 ms·

I’m too young to have used one, but from what I’ve read, it’s the programming model of a single machine with the scale and resilience of a distributed system.

dralley 6y ago
A mainframe is effectively a mail-order on-premise cloud, from the hardware up, developed 3 to 4 decades before things like OpenStack or Kubernetes. Mainframes supported hardware-accelerated virtualization way back in the early 1970s. You could have thousands or tens of thousands of VMs running on a single machine (granted, a machine the size of a room). One of my older greybeard coworkers tells stories of how sometimes an IBM employee would show up at 6 AM to replace a water pump (or some other component) that had phoned home the night before to report that it was beginning to fail. The hardware is super reliable and resilient but also heavily instrumented to detect & resolve failures before they caused problems. And they would send their techs out to pre-empt those problems before the customer ever noticed anything. Not that it would have been too much a problem if it had failed - because there was so much hardware redundancy built into those machines. One of his other stories, is a tech demo that IBM did for his company, where they put a mainframe in the back of a trailer and would drive it around to customer sites. The demo consisted of starting a huge computation on the machine, and pulling up a screen that showed the available hardware resources, then a tech would reach into the machine and start pulling out CPUs and RAM, and you'd watch live as it detected that the hardware had disappeared and shuffled the jobs around to other hardware resources without crashing. And then the tech would start swapping hardware back in, and it would add the resources back into the pool and start doing work with them once again. All handled by the hardware and the OS.
- rbanffy 6y ago
  One of the reasons for that instrumentation is that they used to be operated in a cloud-like environment where the machine is sliced into smaller ones and time on them is billed much like cloud computing is billed today.
  - tablespoon 6y ago
    > One of the reasons for that instrumentation is that they used to be operated in a cloud-like environment where the machine is sliced into smaller ones and time on them is billed much like cloud computing is billed today. IIRC, that's still true. I think IBM mainframes are typically leased, and the customer is billed on usage. There's some complexity to this, where I think the metering only applies to programs in the "traditional" mainframe environment, while things running on the mainframe Linux environment are exempt from metered billing.
    - rbanffy 6y ago
      They still pay for licensed capacity when running things like z/OS. The machine is shipped "full" but the hardware has to be activated by paying a license. One of the interesting features I heard when they launched z15 was that, if one needed to restart a partition, it could tap unlicensed CPUs to start faster and then go back to its licensed capacity.
    - ghaff 6y ago
      I don't know the details of billing these days; it's been a while since I followed the space. But when Linux came out on Z, it ran on something called IFLs. These were not AFAIK physically different from the processors running more traditional IBM workloads. They were simply priced at a lower level. I don't remember if there was capacity on demand for Linux workloads or not.
- nn3 6y ago
  I worked at a place that had a little mainframe (essentially a large server) from IBM to port some software to. Most of the people didn't know anything about mainframes. On a hot day they had an air condition problem in the data center and had to turn off a lot of machines. They tried to turn off the mainframe using the big button, but it just kept running. Then they decided to pull the power plug. System still kept running. It turned out it had an built-in UPS. After some more attempts they finally managed to turn it off.
- 908B64B197 6y ago
  > Basically, rather than handling redundancy in software, they have a ton of hardware-level redundancy to get the high uptime #s. But at what cost? Instead of getting suppliers to out-bid one another you are now stuck in a single supplier situation. [0] Building the redundancy in software allows you to run on commodity hardware that can be purchased from anyone. [0] https://www.gwern.net/Complement https://www.gwern.net/Complement
  - closeparen 6y ago
    Writing a cloud-native distributed system for everything is not free; software development is a bigger expense than raw capacity for many use cases.
zozbot234 6y ago
> it’s the programming model of a single machine with the scale and resilience of a distributed system. Single-system-image clustering delivers on that promise with no dependence on proprietary platforms. Linux is now slowly getting the underlying features needed to enable this (e.g. process migration and checkpointing, namespacing of all system resources), largely as a side-effect of earlier developments such as cgroups. You can already experiment with Linux-CRIU to see what the basic tech is like, it's not fully mainlined yet but it's slowly getting there.
epc 6y ago
For most of their history, IBM mainframes were used for two tasks: batch workloads and interactive users. Batch workloads were things like billing: you're a utility and you need to do the accounting and billing for the million customers you have. You're MCI and you've spent a year advertising Friends and Family discounts and now need to do custom billing every month that figures out all those intersections of friends & family and sends custom billing. Not rocket science, just a lot of boring data crunching you have to do over and over again. Interactive was everything you do today on personal systems: stores had terminal displays that hooked to mainframes for inventory control so salespeople could put together an order or cash registers would transmit sales near real time to a central mainframe and pump into/out of your ERP system. Depending on your company's view of the mainframe world, you might have an MVS system doing all of the batch processing and a VM/TSO system providing interactive. And the MVS system could run under the VM system as a guest O/S, or you could partition the single mainframe to have MVS running on some CECs and VM running on others (e.g. you might have more interactive users during the daytime, then tune down the systems so that the MVS systems had more capacity overnight for batch operations). Mainframes systems could be clustered together in a single data center and you could move workloads back and forth across systems while the workload was in progress. Eventually (circa 1994) you could link mainframe complexes together across DCs to provide redundancy (if a failure occurred in the mainframe equivalent of an AWS AZ the workload could, theoretically, transfer to another AZ with minimal interruption or reconfiguration). On the interactive side…you could have thousands of systems connected to a single mainframe via various forms of I/O systems. All of your retail stores, all of the printers at those stores, frequently all of the security systems, would be set up using APPC or SNA to connect to your regional mainframe over one or more leased POTS lines. The 3270 protocol that drove those green screens was screen oriented, if you changed two fields on the screen and hit ENTER, only the changed data from the fields would be sent, so having a bunch of terminals share a whopping 33kbps line wasn't outrageous. From a programming and systems management perspective, the systems were designed to run as close to maximum utilization as possible. You just spent 10-15-20 million setting up this complex, you want to run it at 90-95% utilization 24 hours a day. So there's a whole set of workload management tools that developed by IBM, CA, and others to tweak applications and the operating environment to run it as hot as possible. There's all sorts of accounting built into the operating system(s) and language environments, going back to when you set literal budgets for how much a given department or program could spend. So, this is the environment that ran from effectively the 1950s through the 1980s into the 1990s. The S/360 line launched in the early 1960s but offered some backwards compatibility to some IBM systems of the 1950s. COBOL gets tagged as the most popular mainframe language but PL/1 (or PL/I) was frequently used (IBM had an internal variant called PL/X which was mostly used for systems software). C was used a lot as well inside IBM but usually for smaller products running inside VM/CMS. I tried writing a web server for MVS in my spare time circa 1995–1996 and even though I was working with people inside MVS development we had a hard time getting it to work with what turned out to be a pretty crappy TCP/IP stack. The batch oriented nature of MVS wasn't the problem, IIRC the TCP/IP stack just could not handle the set up/tear down of the typical HTTP/0.9 and 1.0 connections. When a web server was eventually developed for MVS it was under the posix flavored "OpenEdition". Net: It's just a different model of computing, with a different character set (EBCDIC, still) and languages. It's weird to see the industry kind of / sort of return to the classic shared computing resource model of the cloud with containerized applications and services. IBM in the 1990s was just as convinced at the corporate level that mainframes were dead as the consensus public opinion was at that time, which in retrospect is a shame since IBM chose to fire 1000s of people with the skills it would have needed to leverage to build a competitive cloud offering.

dralley 6y ago

A mainframe is effectively a mail-order on-premise cloud, from the hardware up, developed 3 to 4 decades before things like OpenStack or Kubernetes. Mainframes supported hardware-accelerated virtualization way back in the early 1970s. You could have thousands or tens of thousands of VMs running on a single machine (granted, a machine the size of a room). One of my older greybeard coworkers tells stories of how sometimes an IBM employee would show up at 6 AM to replace a water pump (or some other component) that had phoned home the night before to report that it was beginning to fail. The hardware is super reliable and resilient but also heavily instrumented to detect & resolve failures before they caused problems. And they would send their techs out to pre-empt those problems before the customer ever noticed anything. Not that it would have been too much a problem if it had failed - because there was so much hardware redundancy built into those machines. One of his other stories, is a tech demo that IBM did for his company, where they put a mainframe in the back of a trailer and would drive it around to customer sites. The demo consisted of starting a huge computation on the machine, and pulling up a screen that showed the available hardware resources, then a tech would reach into the machine and start pulling out CPUs and RAM, and you'd watch live as it detected that the hardware had disappeared and shuffled the jobs around to other hardware resources without crashing. And then the tech would start swapping hardware back in, and it would add the resources back into the pool and start doing work with them once again. All handled by the hardware and the OS.

rbanffy 6y ago
One of the reasons for that instrumentation is that they used to be operated in a cloud-like environment where the machine is sliced into smaller ones and time on them is billed much like cloud computing is billed today.
- tablespoon 6y ago
  > One of the reasons for that instrumentation is that they used to be operated in a cloud-like environment where the machine is sliced into smaller ones and time on them is billed much like cloud computing is billed today. IIRC, that's still true. I think IBM mainframes are typically leased, and the customer is billed on usage. There's some complexity to this, where I think the metering only applies to programs in the "traditional" mainframe environment, while things running on the mainframe Linux environment are exempt from metered billing.
  - rbanffy 6y ago
    They still pay for licensed capacity when running things like z/OS. The machine is shipped "full" but the hardware has to be activated by paying a license. One of the interesting features I heard when they launched z15 was that, if one needed to restart a partition, it could tap unlicensed CPUs to start faster and then go back to its licensed capacity.
  - ghaff 6y ago
    I don't know the details of billing these days; it's been a while since I followed the space. But when Linux came out on Z, it ran on something called IFLs. These were not AFAIK physically different from the processors running more traditional IBM workloads. They were simply priced at a lower level. I don't remember if there was capacity on demand for Linux workloads or not.
nn3 6y ago
I worked at a place that had a little mainframe (essentially a large server) from IBM to port some software to. Most of the people didn't know anything about mainframes. On a hot day they had an air condition problem in the data center and had to turn off a lot of machines. They tried to turn off the mainframe using the big button, but it just kept running. Then they decided to pull the power plug. System still kept running. It turned out it had an built-in UPS. After some more attempts they finally managed to turn it off.
908B64B197 6y ago
> Basically, rather than handling redundancy in software, they have a ton of hardware-level redundancy to get the high uptime #s. But at what cost? Instead of getting suppliers to out-bid one another you are now stuck in a single supplier situation. [0] Building the redundancy in software allows you to run on commodity hardware that can be purchased from anyone. [0] https://www.gwern.net/Complement https://www.gwern.net/Complement
- closeparen 6y ago
  Writing a cloud-native distributed system for everything is not free; software development is a bigger expense than raw capacity for many use cases.

zozbot234 6y ago

> it’s the programming model of a single machine with the scale and resilience of a distributed system. Single-system-image clustering delivers on that promise with no dependence on proprietary platforms. Linux is now slowly getting the underlying features needed to enable this (e.g. process migration and checkpointing, namespacing of all system resources), largely as a side-effect of earlier developments such as cgroups. You can already experiment with Linux-CRIU to see what the basic tech is like, it's not fully mainlined yet but it's slowly getting there.

epc 6y ago

For most of their history, IBM mainframes were used for two tasks: batch workloads and interactive users. Batch workloads were things like billing: you're a utility and you need to do the accounting and billing for the million customers you have. You're MCI and you've spent a year advertising Friends and Family discounts and now need to do custom billing every month that figures out all those intersections of friends & family and sends custom billing. Not rocket science, just a lot of boring data crunching you have to do over and over again. Interactive was everything you do today on personal systems: stores had terminal displays that hooked to mainframes for inventory control so salespeople could put together an order or cash registers would transmit sales near real time to a central mainframe and pump into/out of your ERP system. Depending on your company's view of the mainframe world, you might have an MVS system doing all of the batch processing and a VM/TSO system providing interactive. And the MVS system could run under the VM system as a guest O/S, or you could partition the single mainframe to have MVS running on some CECs and VM running on others (e.g. you might have more interactive users during the daytime, then tune down the systems so that the MVS systems had more capacity overnight for batch operations). Mainframes systems could be clustered together in a single data center and you could move workloads back and forth across systems while the workload was in progress. Eventually (circa 1994) you could link mainframe complexes together across DCs to provide redundancy (if a failure occurred in the mainframe equivalent of an AWS AZ the workload could, theoretically, transfer to another AZ with minimal interruption or reconfiguration). On the interactive side…you could have thousands of systems connected to a single mainframe via various forms of I/O systems. All of your retail stores, all of the printers at those stores, frequently all of the security systems, would be set up using APPC or SNA to connect to your regional mainframe over one or more leased POTS lines. The 3270 protocol that drove those green screens was screen oriented, if you changed two fields on the screen and hit ENTER, only the changed data from the fields would be sent, so having a bunch of terminals share a whopping 33kbps line wasn't outrageous. From a programming and systems management perspective, the systems were designed to run as close to maximum utilization as possible. You just spent 10-15-20 million setting up this complex, you want to run it at 90-95% utilization 24 hours a day. So there's a whole set of workload management tools that developed by IBM, CA, and others to tweak applications and the operating environment to run it as hot as possible. There's all sorts of accounting built into the operating system(s) and language environments, going back to when you set literal budgets for how much a given department or program could spend. So, this is the environment that ran from effectively the 1950s through the 1980s into the 1990s. The S/360 line launched in the early 1960s but offered some backwards compatibility to some IBM systems of the 1950s. COBOL gets tagged as the most popular mainframe language but PL/1 (or PL/I) was frequently used (IBM had an internal variant called PL/X which was mostly used for systems software). C was used a lot as well inside IBM but usually for smaller products running inside VM/CMS. I tried writing a web server for MVS in my spare time circa 1995–1996 and even though I was working with people inside MVS development we had a hard time getting it to work with what turned out to be a pretty crappy TCP/IP stack. The batch oriented nature of MVS wasn't the problem, IIRC the TCP/IP stack just could not handle the set up/tear down of the typical HTTP/0.9 and 1.0 connections. When a web server was eventually developed for MVS it was under the posix flavored "OpenEdition". Net: It's just a different model of computing, with a different character set (EBCDIC, still) and languages. It's weird to see the industry kind of / sort of return to the classic shared computing resource model of the cloud with containerized applications and services. IBM in the 1990s was just as convinced at the corporate level that mainframes were dead as the consensus public opinion was at that time, which in retrospect is a shame since IBM chose to fire 1000s of people with the skills it would have needed to leverage to build a competitive cloud offering.