4 ms·

This actually got me fairly curious as to what the big difference is between mainframes and regular ol' micros. I don't think I ever used a proper mainframe, an

This actually got me fairly curious as to what the big difference is between mainframes and regular ol' micros. I don't think I ever used a proper mainframe, and I honestly wanted to know more. The author keeps building up to this massively different, otherworldly system, and then just finishes without ever answering. I did feel some contempt towards certain developers (who dare call themselves software engineers) and there was definitely an "old man yelling at cloud" undercurrent. If only I could learn something of merit, that would have been worth it. So I guess it's up to us plebs to go and see what makes mainframes so different. How the "weird" custom architectures work. What's it like to work on one and write code for it.

Tor3 4y ago
The maybe most distinguishing feature of a "mainframe" is intelligent I/O channels, which offloads a lot of what would otherwise be CPU work. And those I/O channels is why the PDP-10 was called a "mainframe" while the rest of the PDP series (without I/O channels) were called "minicomputers". There's more, but it depends on the system - some can do maintenance on parts of the system while still operating.
- HyperSane 4y ago
  The x86 world is getting I/O channels in the form of "SmartNICs" which are NICs with substantial processing power.
  - rbanffy 4y ago
    They also have it with disks local and remote. The idea is that the CPU is running user code 100% of the time and that it doesn’t need to wait for anything.
    - neverartful 4y ago
      With the mainframe all disks are external. This diagram [0] does a good job of showing that. [0] https://en.wikipedia.org/wiki/Count_key_data#/media/File:IBM_CKD_Arch.png https://en.wikipedia.org/wiki/Count_key_data#/media/File:IBM...
      - HyperSane 4y ago
        Most enterprise servers use external storage arrays.
    - trasz 4y ago
      In the PC world this has been done couple of times, eg https://en.m.wikipedia.org/wiki/I2O https://en.m.wikipedia.org/wiki/I2O from the late 90’s. I think the real reason why it works for mainframes is that their operating system is so primitive, so it’s easy to cross layers - because there are so few of them. z/OS is closer to MS-DOS than to Unix in that regard.
- Sebb767 4y ago
  > some can do maintenance on parts of the system while still operating. That's not that rare these days. Basically any server will allow hot-plugging hard drives, with some configurations network cards and by now a lot of laptops can even hot-plug GPUs via Thunderbolt.
  - deleted 4y ago
    [deleted]
  - rbanffy 4y ago
    I remember some big iron could do it with processors and memory as well. IIRC, you can no longer remove CPUs with IBMs, but replacing memory is relatively simple.
  - neverartful 4y ago
    Hot-plugging hard drives is a bare minimum. There are many other points of failure and a failure of any of the following WILL result in downtime while the component is replaced: disk controller, CPU, memory, NIC. Having dual NICs and dual processors helps, but it's still a far cry from 100% availability.
neverartful 4y ago
If you want to quickly get a feel for traditional IBM mainframe software, you can do that easily enough. Download Hercules mainframe emulator [0] and then you can fire up MVS 3.8 [1] or VM/370 [2]. Be aware that the community has made significant improvements on these old open source software systems. [0] http://www.hercules-390.org [1] https://www.jaymoseley.com/hercules/installMVS/iPREREQv7.htm [2] http://gunkies.org/wiki/Installing_VM/370_on_Hercules
lproven 4y ago
Hi. I wrote the piece. Thanks for taking the time to read it. I wasn't aiming or trying to give a worked example of the differences, though. That's in the link that inspired the comment. Didn't you look at that? It's exactly what you ask, with discussions of filesystems, CLI, even C code examples. It would have been redundant to try to duplicate that. It's why I recommended it. I still do. You should read it, because it sounds like what you want to me. https://arcanesciences.com/os2200/ https://arcanesciences.com/os2200/ As for sounding like a grumpy old man -- well: “I don't mean to sound bitter, cold, or cruel, but I am, so that's how it comes out.” ― Bill Hicks :-D It's only a comment from Lobste.rs, copied-and-pasted. It might grow into something more significant at some time. Might not. Can't promise.
Animats 4y ago
> The author keeps building up to this massively different, otherworldly system, and then just finishes without ever answering. Yes, it's a weak article. So, what do mainframes have that microcomputers don't? - Much more internal checking. Everything has parity or ECC. CPUs have internal checking. There are interrupts for "CPU made a mistake", and OSs which can take corrective action. - Channels. Mainframes have channel controllers. These connect to devices on one end, and the main CPUs and memory on the other. They work in a standardized way, independent of the device. The channel controllers control what data goes to and from the devices. Sometimes they even control what a program can say to a device, so that an application can be given direct device access with access restrictions. This would, for example, let a database talk to a disk partition without going through the OS, but limit it to that partition. The channel controllers determine where peripherals put data in memory. Mainframes have specific I/O instructions for talking to the channel controllers. Drivers in user space have been around since the 1960s. Minicomputers and microcomputers, on the other hand, once had peripherals directly connected to the memory bus. Programs talked to peripherals by storing and loading values into "device registers". There were no specific I/O instructions built into the CPU. Some devices accessed memory themselves, called "direct memory access", or DMA. They could write anywhere in memory, a security and reliability problem. Microcomputer CPUs haven't worked that way for decades. Not since the era of ISA peripherals. But they still pretend to. Programs use store instructions to store into what appears to the CPU is a memory block. But that's really going to what's called the "southbridge", which is logic that sends commands to devices. Those devices offer an interface which appears like memory, but is really piping a command to logic in the device. On the memory access side, the program stores into "device registers" which tell the "northbridge" to set up data access between devices and memory. Sometimes today there's a memory management unit between peripherals and main memory, to control where they can store. The end result is something more complicated than a mainframe channel, but without the architectural advantages of isolating the devices from the CPU. Attempts have been made to fix this. Intel has tried various types of I/O controllers. But the architecture of Unix/Linux isn't channel-oriented, so it just adds a layer of indirection that makes drivers more difficult. (Then came GPUs, which started as peripheral devices and gradually took over, but that's a whole other subject.) - Virtual machine architecture The first computer that could virtualize itself was the IBM System 360/67, in the 1960s. This worked well enough that all the System/370 machines had virtual machine capability. Unlike the mess in x86 world, the virtual machine and the real machine look very similar. Similar enough that you can load an OS intended for raw hardware into a virtual machine. This even stacks; you can load another copy of the OS inside a VM of the first OS. I've heard of someone layering this 10 deep. The way x86 machines do virtualization required adding a special layer in hardware underneath the main layer, although, over time, it's become more general in x86 land. Arm AArch64 considered virtualization from the start, and may be saner.

Tor3 4y ago

The maybe most distinguishing feature of a "mainframe" is intelligent I/O channels, which offloads a lot of what would otherwise be CPU work. And those I/O channels is why the PDP-10 was called a "mainframe" while the rest of the PDP series (without I/O channels) were called "minicomputers". There's more, but it depends on the system - some can do maintenance on parts of the system while still operating.

HyperSane 4y ago
The x86 world is getting I/O channels in the form of "SmartNICs" which are NICs with substantial processing power.
- rbanffy 4y ago
  They also have it with disks local and remote. The idea is that the CPU is running user code 100% of the time and that it doesn’t need to wait for anything.
  - neverartful 4y ago
    With the mainframe all disks are external. This diagram [0] does a good job of showing that. [0] https://en.wikipedia.org/wiki/Count_key_data#/media/File:IBM_CKD_Arch.png https://en.wikipedia.org/wiki/Count_key_data#/media/File:IBM...
    - HyperSane 4y ago
      Most enterprise servers use external storage arrays.
  - trasz 4y ago
    In the PC world this has been done couple of times, eg https://en.m.wikipedia.org/wiki/I2O https://en.m.wikipedia.org/wiki/I2O from the late 90’s. I think the real reason why it works for mainframes is that their operating system is so primitive, so it’s easy to cross layers - because there are so few of them. z/OS is closer to MS-DOS than to Unix in that regard.
Sebb767 4y ago
> some can do maintenance on parts of the system while still operating. That's not that rare these days. Basically any server will allow hot-plugging hard drives, with some configurations network cards and by now a lot of laptops can even hot-plug GPUs via Thunderbolt.
- deleted 4y ago
  [deleted]
- rbanffy 4y ago
  I remember some big iron could do it with processors and memory as well. IIRC, you can no longer remove CPUs with IBMs, but replacing memory is relatively simple.
- neverartful 4y ago
  Hot-plugging hard drives is a bare minimum. There are many other points of failure and a failure of any of the following WILL result in downtime while the component is replaced: disk controller, CPU, memory, NIC. Having dual NICs and dual processors helps, but it's still a far cry from 100% availability.

neverartful 4y ago

If you want to quickly get a feel for traditional IBM mainframe software, you can do that easily enough. Download Hercules mainframe emulator [0] and then you can fire up MVS 3.8 [1] or VM/370 [2]. Be aware that the community has made significant improvements on these old open source software systems. [0] http://www.hercules-390.org [1] https://www.jaymoseley.com/hercules/installMVS/iPREREQv7.htm [2] http://gunkies.org/wiki/Installing_VM/370_on_Hercules

lproven 4y ago

Hi. I wrote the piece. Thanks for taking the time to read it. I wasn't aiming or trying to give a worked example of the differences, though. That's in the link that inspired the comment. Didn't you look at that? It's exactly what you ask, with discussions of filesystems, CLI, even C code examples. It would have been redundant to try to duplicate that. It's why I recommended it. I still do. You should read it, because it sounds like what you want to me. https://arcanesciences.com/os2200/ https://arcanesciences.com/os2200/ As for sounding like a grumpy old man -- well: “I don't mean to sound bitter, cold, or cruel, but I am, so that's how it comes out.” ― Bill Hicks :-D It's only a comment from Lobste.rs, copied-and-pasted. It might grow into something more significant at some time. Might not. Can't promise.

Animats 4y ago

> The author keeps building up to this massively different, otherworldly system, and then just finishes without ever answering. Yes, it's a weak article. So, what do mainframes have that microcomputers don't? - Much more internal checking. Everything has parity or ECC. CPUs have internal checking. There are interrupts for "CPU made a mistake", and OSs which can take corrective action. - Channels. Mainframes have channel controllers. These connect to devices on one end, and the main CPUs and memory on the other. They work in a standardized way, independent of the device. The channel controllers control what data goes to and from the devices. Sometimes they even control what a program can say to a device, so that an application can be given direct device access with access restrictions. This would, for example, let a database talk to a disk partition without going through the OS, but limit it to that partition. The channel controllers determine where peripherals put data in memory. Mainframes have specific I/O instructions for talking to the channel controllers. Drivers in user space have been around since the 1960s. Minicomputers and microcomputers, on the other hand, once had peripherals directly connected to the memory bus. Programs talked to peripherals by storing and loading values into "device registers". There were no specific I/O instructions built into the CPU. Some devices accessed memory themselves, called "direct memory access", or DMA. They could write anywhere in memory, a security and reliability problem. Microcomputer CPUs haven't worked that way for decades. Not since the era of ISA peripherals. But they still pretend to. Programs use store instructions to store into what appears to the CPU is a memory block. But that's really going to what's called the "southbridge", which is logic that sends commands to devices. Those devices offer an interface which appears like memory, but is really piping a command to logic in the device. On the memory access side, the program stores into "device registers" which tell the "northbridge" to set up data access between devices and memory. Sometimes today there's a memory management unit between peripherals and main memory, to control where they can store. The end result is something more complicated than a mainframe channel, but without the architectural advantages of isolating the devices from the CPU. Attempts have been made to fix this. Intel has tried various types of I/O controllers. But the architecture of Unix/Linux isn't channel-oriented, so it just adds a layer of indirection that makes drivers more difficult. (Then came GPUs, which started as peripheral devices and gradually took over, but that's a whole other subject.) - Virtual machine architecture The first computer that could virtualize itself was the IBM System 360/67, in the 1960s. This worked well enough that all the System/370 machines had virtual machine capability. Unlike the mess in x86 world, the virtual machine and the real machine look very similar. Similar enough that you can load an OS intended for raw hardware into a virtual machine. This even stacks; you can load another copy of the OS inside a VM of the first OS. I've heard of someone layering this 10 deep. The way x86 machines do virtualization required adding a special layer in hardware underneath the main layer, although, over time, it's become more general in x86 land. Arm AArch64 considered virtualization from the start, and may be saner.