Return to Answer

TL;DR: one non recoverable error per 32 KiB and month.

TL;DR: one non recoverable error per 32 KiB per month.

Caveat: I can only tell about mainframes. Minis might have used different protection and handling schemes (and for sure smaller memory sizes). My detailed knowledge is based on memory up to the mid-1970s. Further I was working for a manufacturer of compatible mainframes. We switched already for complete semiconductor memory at a time when IBM introduced new generations of core, but I don't remember them being any better, just smaller.

Caveat: I can only tell about mainframes. Minis might have used different protection and handling schemes (and for sure smaller memory sizes). My detailed knowledge is based on memory up to the mid-1970s. Further I was working for a manufacturer of compatible mainframes. We switched already for complete semiconductor memory at a time when IBM introduced new generations of core, but I don't remember these new core modules being any better, just smaller.

Caveat: I can only tell about mainframes. Minis might have used different protection and handling schemes (and for sure smaller memory sizes). My detailed knowledge is based on memory up to the mid-1970s. Further I was working for a manufacturer of compatible mainframes. We switched already for complete semiconducter memory at a time when IBM introduced new generations of core, but I don't remember them being any better, just smaller.

Flipped bits happened all the time during normal operation. Rule of thumb, for mainframes using error detection and correction, was one non correctable error per 32 KiB and month at 24/7 usage. This rate was considered acceptable. Back then mainframe programms where usually batch runs and build around checkpoints.

Since only very few customer machines used more than 128-256 KiB (in fact, even 'large' models couldn't even be extended past that) during the 60s and early 70s, one or two machine halt per week was considered ok. After all, compared to previous systems this was an astonishing smooth handling.

When a parity halt occured, depending on the jobs running, operators did check where the faulty word was (location, programm) and either patched it back, reload some stuff or just purged that single programm and let the machine continue. No reboot or alike. Yes, beeing an operator back then meant that you really knew the programms running.

Now with dialog applications and huge memory sizes the picture was a bit different. The most extreme example here might have been the 1972 Olympics. It included the first integrated real time online information system for the media, where all results were available at online terminals thruout the press center less than a minute after each and every competition. Several hundred aquisition stations and terminals where spread out literally all over Germany (while the main event was in Munich, some competitions like boating happened up at the north sea coast), while again hundreds of terminals where located at the main press center in Munich. So newspaper reporters could produce reports without moving their butt past the coffee maker. But that's a different story.

At the core one mainframe handled all the data aquisition and dialog load and it's been one of the largest installations worldwide, if not the largest up to that time. 32 disk drives and a whooping two megabytes RAM in single installation. The machine had to be setup in a T-shape with memory in all crossbar cabinets to keep the wire length toward the CPU (vertical bar) as short as possible, while having equal length to all cabinets (again, a different story). In theory this machine should get about two non recoverable errors per day and it worked out that way, even careful component selection couldn't reduce this much. There were more than a dozen machine halts during the 14 days of operation. It was still a quite successful operation, as, thanks to the back then brandnew data base system a start up happened in less than 90 seconds - including OS boot. So failures became more of a small glitch than a real issue.

(Insert: The ability to run a large scale real time information system (even for todays standards not small) on a machine with 'just' 2 MiB RAM, less than 200 MiB Disk and 400 kOps is a great example that a mainframe MIPS are incomparable to mini/microprocessor MIPS)

Procedure for a clean power off while retaining machine state and memory was to put the CPU on hold and then power off. Hold wasn't an interrupt or alike, but literally held the CPU, so no further operation was done. There was a seperate HOLD button at the operator's console. When powered on again, just press HOLD again to have it continue - or change some registers, like PC, to have it start somewhere else.

This mechanic is why some mainframe manufacturers added special machine error state (a combination of interrupt and separate register set) which was invoked at power fail. The power supply did provide sufficient power to run a few instructions after power failure was detected. More than enough time to execute a single hold instruction, followed by some code to return from interrupt or put it into any kind of recovery mode. No UPS, large scale capacitor or motor generator needed, it just stopped and continued after power off/on. Ofc, this did only affect the CPU. Half written tape blocks or disk tracks where still a pile of garbage. That's where checkpoints again played a role.

Mainframes aren't a pile of single solutions as todays small machines, but a clockwork of multiple use of inherent hardware features.

Caveat: I can only tell about mainframes. Minis might have used different protection and handling schemes (and for sure smaller memory sizes). My detailed knowledge is based on memory up to the mid-1970s. Further I was working for a manufacturer of compatible mainframes. We switched already for complete semiconductor memory at a time when IBM introduced new generations of core, but I don't remember them being any better, just smaller.

Flipped bits happened all the time during normal operation. Rule of thumb, for mainframes using error detection and correction, was one non correctable error per 32 KiB and month at 24/7 usage. This rate was considered acceptable. Back then mainframe programs where usually batch runs and build around checkpoints.

Since only very few customer machines used more than 128-256 KiB (in fact, even 'large' models couldn't even be extended past that) during the 60s and early 70s, one or two machine halt per week was considered OK. After all, compared to previous systems this was an astonishing smooth handling.

When a parity halt occurred, depending on the jobs running, operators did check where the faulty word was (location, program) and either patched it back, reload some stuff or just purged that single program and let the machine continue. No reboot or alike. Yes, being an operator back then meant that you really knew the programs running.

Now with dialog applications and huge memory sizes the picture was a bit different. The most extreme example here might have been the 1972 Olympics. It included the first integrated real time online information system for the media, where all results were available at online terminals throughout the press center less than a minute after each and every competition. Several hundred acquisition stations and terminals where spread out literally all over Germany (while the main event was in Munich, some competitions like boating happened up at the north sea coast), while again hundreds of terminals where located at the main press center in Munich. So newspaper reporters could produce reports without moving their butt past the coffee maker. But that's a different story.

At the core one mainframe handled all the data acquisition and dialog load and it's been one of the largest installations worldwide, if not the largest up to that time. 32 disk drives and a whopping two megabytes RAM in single installation. The machine had to be setup in a T-shape with memory in all crossbar cabinets to keep the wire length toward the CPU (vertical bar) as short as possible, while having equal length to all cabinets (again, a different story). In theory this machine should get about two non recoverable errors per day and it worked out that way, even careful component selection couldn't reduce this much. There were more than a dozen machine halts during the 14 days of operation. It was still a quite successful operation, as, thanks to the back then brand new data base system a start up happened in less than 90 seconds - including OS boot. So failures became more of a small glitch than a real issue.

(Insert: The ability to run a large scale real time information system (even for today's standards not small) on a machine with 'just' 2 MiB RAM, less than 200 MiB Disk and 400 kOps is a great example that a mainframe MIPS are incomparable to mini/microprocessor MIPS)

Procedure for a clean power off while retaining machine state and memory was to put the CPU on hold and then power off. Hold wasn't an interrupt or alike, but literally held the CPU, so no further operation was done. There was a separate HOLD button at the operator's console. When powered on again, just press HOLD again to have it continue - or change some registers, like PC, to have it start somewhere else.

This mechanic is why some mainframe manufacturers added special machine error state (a combination of interrupt and separate register set) which was invoked at power fail. The power supply did provide sufficient power to run a few instructions after power failure was detected. More than enough time to execute a single hold instruction, followed by some code to return from interrupt or put it into any kind of recovery mode. No UPS, large scale capacitor or motor generator needed, it just stopped and continued after power off/on. Of course, this did only affect the CPU. Half written tape blocks or disk tracks where still a pile of garbage. That's where checkpoints again played a role.

Mainframes aren't a pile of single solutions as today's small machines, but a clockwork of multiple use of inherent hardware features.