I think you underestimate impact of micros. At lowest end ZX Spectrum
and Commodre 64 gave nontrivial compute power at low cost. There was
IBM PC and 68000-based workstations. So already around 1983 micros
limited market for low end minis (and due to minis market for low end
mainfraimes was limited earlier).
What define(s|d) a "mini" or a "mainframe"?
According to Stefan Monnier <[email protected]>:
I think you underestimate impact of micros. At lowest end ZX Spectrum
and Commodre 64 gave nontrivial compute power at low cost. There was
IBM PC and 68000-based workstations. So already around 1983 micros
limited market for low end minis (and due to minis market for low end
mainfraimes was limited earlier).
What define(s|d) a "mini" or a "mainframe"?
If you'll look through the archives, we've had this discussion before.
To me the difference is the I/O architecture. If it has channels that do
a lot
of I/O between interrupts it's a mainframe. If it takes an interrupt or otherwise involves the CPU for each word transferred, it's a mini. So
the 360/30
was a very small mainframe and the PDP-10 was a very large mini.
The distinction is somewhat fuzzy. A PDP-8 was a mini that took
interrupts on
each word for most devices like terminals and printers, but for fast
devices
like disks and drums, it had DMA that could do one block at a time,
stealing
memory cycles as needed. Same for the PDP-10. (Many of the same devices,
in
fact.)
I think everyone agrees that 360s were mainframes, but a lot of people disagree
with me about the PDP-10, arguing that it was marketed as a mainframe,
which it
kind of was, although its I/O was a lot weaker than any 360's.
I basically agree with this definition.
However it leaves the door open for a microprocessor with a 40GHz
ethernet NIC device down on a PCIe tree to be deemed a mainframe.
Another definition of mainframe is RAS--Reliability, Availability, >Serviceability, where hardware detects all sort of anomalous events
and interrupts and informs software of bad things going on. This
is way beyond "just ECC" checking.
Right. An IBM zSeries mainframe has a lot of CPUs, some of which are on hot standby so they can be switched in if another CPU fails, restarting in the middle of an instruction if need be. They are also designed so parts of
them can be taken offline and even physically disconnected without stopping the system, allowing hardware upgrades without a reboot. I hear it is not unknown for them to go a decade between reboots.
the system, allowing hardware upgrades without a reboot. I hear it is not >> unknown for them to go a decade between reboots.
I find it hard to imagine that over a decade there would not be enough >bugfixes and enhancements to justify a reboot much earlier, in order
to get the better OS revvision in place. But I also imagine that these
IBM mainframes are all clusters (sysplexes) where one can reboot one CPU
at a time while the workload keeps running.
On 2025-06-21, John Levine <[email protected]> wrote:
Right. An IBM zSeries mainframe has a lot of CPUs, some of which are on
hot
standby so they can be switched in if another CPU fails, restarting in
the
middle of an instruction if need be. They are also designed so parts of
them can be taken offline and even physically disconnected without
stopping
the system, allowing hardware upgrades without a reboot. I hear it is
not
unknown for them to go a decade between reboots.
I find it hard to imagine that over a decade there would not be enough bugfixes and enhancements to justify a reboot much earlier, in order
to get the better OS revvision in place. But I also imagine that these
IBM mainframes are all clusters (sysplexes) where one can reboot one CPU
at a time while the workload keeps running.
On 2025-06-21, John Levine <[email protected]> wrote:
Right. An IBM zSeries mainframe has a lot of CPUs, some of which are on hot >> standby so they can be switched in if another CPU fails, restarting in the >> middle of an instruction if need be. They are also designed so parts of
them can be taken offline and even physically disconnected without stopping >> the system, allowing hardware upgrades without a reboot. I hear it is not >> unknown for them to go a decade between reboots.
I find it hard to imagine that over a decade there would not be enough bugfixes and enhancements to justify a reboot much earlier, in order
to get the better OS revvision in place.
On 2025-06-21, John Levine <[email protected]> wrote:
Right. An IBM zSeries mainframe has a lot of CPUs, some of which are on hot >> standby so they can be switched in if another CPU fails, restarting in the >> middle of an instruction if need be. They are also designed so parts of
them can be taken offline and even physically disconnected without stopping >> the system, allowing hardware upgrades without a reboot. I hear it is not >> unknown for them to go a decade between reboots.
I find it hard to imagine that over a decade there would not be enough bugfixes and enhancements to justify a reboot much earlier, in order
to get the better OS revvision in place. But I also imagine that these
IBM mainframes are all clusters (sysplexes) where one can reboot one CPU
at a time while the workload keeps running.
According to Stefan Monnier <[email protected]>:
I think you underestimate impact of micros. At lowest end ZX Spectrum
and Commodre 64 gave nontrivial compute power at low cost. There was
IBM PC and 68000-based workstations. So already around 1983 micros
limited market for low end minis (and due to minis market for low end
mainfraimes was limited earlier).
What define(s|d) a "mini" or a "mainframe"?
If you'll look through the archives, we've had this discussion before.
To me the difference is the I/O architecture. If it has channels that do a lot
of I/O between interrupts it's a mainframe. If it takes an interrupt or otherwise involves the CPU for each word transferred, it's a mini. So the 360/30
was a very small mainframe and the PDP-10 was a very large mini.
Even more fuzzy were models keeping microcode in core: IIUC in principle determined user could take over microcode store and run user programs directly on the hardware. That way machine would be more like a
mini with rather inconvenient instruction set, but much faster than
using 360 instruction set.
On Sun, 22 Jun 2025 22:15:41 +0000, Lynn Wheeler wrote:
Boeblingon (germany) 115/125 was even more divergent. They had nine
position memory bus for microprocessors. For 115, all the
microprocessors were the same, one running 370 microcode (avg ten native
instructions/370 instruction, at about 370 80KIPS) and others running
(I/O integrated) "controller" microcode. The 125 was the same but the
microprocessor running 370 microcode was 50% faster .... getting about
370 120KIPS (1.2MIPS native microprocessor).
While the System/370 Model 115 was discontinued in 1981,
the year the IBM PC was introduced, the Model 115 was
itself introduced in 1973. They didn't really have
microprocessors back then. (With perhaps some exotic
exceptions...)
John Savard
On the other hand, the 4004 wasn't exotic. And since the Intel 8008
dates from 1972, I was wrong to think that 8-bit microprocessors were >nonexistent in 1973, so it was not correct for me to claim that it was >impossible for the IBM 370/115 to have used some sort of microprocessor
as its basis - even if I still would tend to suspect that it was
unlikely.
The ROMP project started in 1977. I'm not aware of any IBM micros before that. They called the 5100's PALM a microprocessor but that was because
it ran microcode. It was a dozen gate arrays, not a single chip.
On Mon, 23 Jun 2025 23:16:13 +0000, John Levine wrote:
In that era IBM made their own chips, so there's no way they'd have used
an Intel microprocessor.
Oh, yes, I realize that. And an 8008 wouldn't have corresponded to
what had been claimed to have been used in the System/360 model 115:
a microprocessor that could either execute microcode to implement the System/370 instruction set, or microcode to function as a channel.
Whatever type of circuitry IBM used in the 370/115, and whether or not,
even if it took multiple chips, it could be termed a "microprocessor"
by any common definition, I do not know. I simply noted the 8008 as
showing that I was mistaken in dismissing the possibility of an IBM
designed microprocessor in the 115 out of hand; the technology did
exist at that time.
John Savard
On Tue, 24 Jun 2025 0:25:47 +0000, quadibloc wrote:
On Mon, 23 Jun 2025 23:16:13 +0000, John Levine wrote:
In that era IBM made their own chips, so there's no way they'd have used >>> an Intel microprocessor.
Oh, yes, I realize that. And an 8008 wouldn't have corresponded to
what had been claimed to have been used in the System/360 model 115:
a microprocessor that could either execute microcode to implement the
System/370 instruction set, or microcode to function as a channel.
For the record, as a fun side-project, I wrote 8085 asm to interpret
the 360 ISA.
On Mon, 23 Jun 2025 23:16:13 +0000, John Levine wrote:
In that era IBM made their own chips, so there's no way they'd have used
an Intel microprocessor.
Oh, yes, I realize that.
On Sat, 21 Jun 2025 20:27:05 +0000, Lars Poulsen wrote:
On 2025-06-21, John Levine <[email protected]> wrote:
Right. An IBM zSeries mainframe has a lot of CPUs, some of which are on
hot
standby so they can be switched in if another CPU fails, restarting in
the
middle of an instruction if need be. They are also designed so parts of >>> them can be taken offline and even physically disconnected without
stopping
the system, allowing hardware upgrades without a reboot. I hear it is
not
unknown for them to go a decade between reboots.
I find it hard to imagine that over a decade there would not be enough
bugfixes and enhancements to justify a reboot much earlier, in order
to get the better OS revvision in place. But I also imagine that these
IBM mainframes are all clusters (sysplexes) where one can reboot one CPU
at a time while the workload keeps running.
When we closed down one company, the SPARC server had an uptime of
7 years 6 months. Every CPU had been replaced several times, memory
had grown 4× and the disks by 5× count and 25× space. All without needing to reboot the thing. And the building had had numerous power failures, struck by lightening, and had the main power transformer
blow up 100 yards from the building in a lightening storm. Yet it
continued to run.
If I look at my PC with crossed eyes it crashes .....
On Tue, 24 Jun 2025 0:25:47 +0000, quadibloc wrote:
On Mon, 23 Jun 2025 23:16:13 +0000, John Levine wrote:
In that era IBM made their own chips, so there's no way they'd have used >>> an Intel microprocessor.
Oh, yes, I realize that. And an 8008 wouldn't have corresponded to
what had been claimed to have been used in the System/360 model 115:
a microprocessor that could either execute microcode to implement the
System/370 instruction set, or microcode to function as a channel.
For the record, as a fun side-project, I wrote 8085 asm to interpret
the 360 ISA.
Whatever type of circuitry IBM used in the 370/115, and whether or not,
even if it took multiple chips, it could be termed a "microprocessor"
by any common definition, I do not know.
According to quadibloc <[email protected]>:
On the other hand, the 4004 wasn't exotic. And since the Intel 8008
dates from 1972, I was wrong to think that 8-bit microprocessors were >>nonexistent in 1973, so it was not correct for me to claim that it was >>impossible for the IBM 370/115 to have used some sort of microprocessor
as its basis - even if I still would tend to suspect that it was
unlikely.
In that era IBM made their own chips, so there's no way they'd have used
an Intel microprocessor.
quadibloc <[email protected]> wrote:
Whatever type of circuitry IBM used in the 370/115, and whether or not,
even if it took multiple chips, it could be termed a "microprocessor"
by any common definition, I do not know.
My impression was that original meaning of "microprocessor" was
"processor executing microcode". IBM build a lot of them.
AFAICS the 370/115 reference is using this meaning. When
highly integrated processors became possible, "microprocessors"
(in this sense) were clear target, as they were simpler than
normal "user" architecture. Also, some "microprocessors"
where low performance ones, so even very early microprocessor
had adequate performance to serve as a replacement.
According to quadibloc <[email protected]>:
On the other hand, the 4004 wasn't exotic. And since the Intel 8008
dates from 1972, I was wrong to think that 8-bit microprocessors were
nonexistent in 1973, so it was not correct for me to claim that it was
impossible for the IBM 370/115 to have used some sort of microprocessor
as its basis - even if I still would tend to suspect that it was
unlikely.
In that era IBM made their own chips, so there's no way they'd have used
an Intel microprocessor.
The ROMP project started in 1977. I'm not aware of any IBM micros before that. They called the 5100's PALM a microprocessor but that was because
it ran microcode. It was a dozen gate arrays, not a single chip.
It was, as you admit, large. Given that PDP-10s were often used in
timeshared installations, I would be surprised if there wasn't something present to prevent the PDP-10 central computer from being directly
involved with every character coming from every terminal.
On 22/06/2025 01:55, quadibloc wrote:
It was, as you admit, large. Given that PDP-10s were often used in
timeshared installations, I would be surprised if there wasn't something
present to prevent the PDP-10 central computer from being directly
involved with every character coming from every terminal.
A little memory just floated up from 40 odd years ago - our one at Uni
had something to handle the terminals, which was basically a PDP/11. But
I don't recall any details. I was supposed to be studying Biology.
According to Vir Campestris <[email protected]d>:
On 22/06/2025 01:55, quadibloc wrote:
It was, as you admit, large. Given that PDP-10s were often used in
timeshared installations, I would be surprised if there wasn't something >>> present to prevent the PDP-10 central computer from being directly
involved with every character coming from every terminal.
A little memory just floated up from 40 odd years ago - our one at Uni
had something to handle the terminals, which was basically a PDP/11. But
I don't recall any details. I was supposed to be studying Biology.
The KL-10 and KL-20 had a PDP-11 front end that handled maintenance functions >and slow peripherals including the terminals. Here's a manual:
https://bitsavers.org/pdf/dec/pdp10/KL10/EK-OKL10-TM_KL10_TechRef_Aug84.pdf
Using a separate smaller computer to handle terminals was a common idea. The >first version of Dartmouth's DTSS put most of the system in a slow front end >computer, using the large computer as a compute server. The later version with a
GE635 was more conventionally structured but still ran the terminals through the
front end computer which only passed chunks of terminal input to the main >computer when there something for it to do, e.g., the user typed RUN or LIST.
One of the first computers I used in the late 1960s was a PDP-6 at Applied Logic
in Princeton NJ. They had somehow lashed up a PDP-8 to run out of the high 4K of
the PDP-6 memory, so the PDP-8 did the terminal I/O thrugh the amazing 680 one >bit at a time terminal multiplexor. I am not aware of any documentation for >this, but I know it was real since I saw it and used it.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 32:30:39 |
| Calls: | 12,109 |
| Files: | 15,006 |
| Messages: | 6,518,298 |