Advent of Computing - Episode 190 - Machine Room or DEATH TRAP!?

Episode Date: October 4, 2026

Boo! Welcome to Spook Month 2026! I start off my scary coverage by looking at the dangers of the mainframe rooms of the 50s and 60s. We all know that running computers can be a drag. But can it be deadly? Answering that question takes me through government documents, maintenance manuals, and odd recollections of days gone by. Like Advent of Computing? Then check out the after show! Adjunct of Computing is now LIVE: YouTube Spotify Apple Podcasts Join the conversation on the OFFICIAL discord server: https://discord.com/invite/GpFNu3DTU2

Working a computer back in the day, well, that was a hard job. We have it easy. Today, you just press a button and the computer's ready to roll. You can even touch that button yourself. But in the far-flung past, computing was more akin to a cult than a career or even an everyday activity. Computers were enshrined in special machine rooms. These were custom-built to hold the precious apparatus itself.

These rooms were peopled by a class of clerics called operators. It was the operator's job to protect their machine from the unwashed masses. For an outsider to use a computer, they had to first submit their request to an operator. Even then, the novice would never approach the machine. An operator acted on their behalf, besieching the digital beast with gentle prodding. These operators lived chained to their computers. Shifts rotated in and out of machine rooms, keeping the computer operational at all hours of the day.

It was a taxing and exacting job. Maintaining one of these beasts took real skill and real experience. Everything from code and heavy grease and oil to hammer and solder was used. All to keep the beast eating data. Hard work to be sure. But the question is, could this beast rear back and turn on its very operators? Were these shrines computing truly dangerous to their own clerics? Welcome back to Advent of Computing.

I'm your host, Sean Hass. And this, well, it's the start of Spook Month, 2026. Each October, it's become customary to run episodes about the skin. spooky and frustrating side of computing. The conceit of the whole project is that computers are rarely actually frightening. They're more likely to inspire groans and sleepless nights than true terror. So this month, you're getting four small episodes, each cast from a spooky mold. To start with is episode 190, Machine Room, or Death Trap.

Now, this has been something that I never put. it together until recently. In preparation for this month, I ran into a 1976 report from the U.S. Senate's Committee on Government Operations, titled Computer Abuses. What can I say? I've been finding some well-named federal reports lately. This report has a whole section on the dangers the computer rooms face. These range from fire to flooding to downright sabotage. That was enough to get me connect in the dots. So we have one question today. How dangerous were old machine rooms? Were they truly a risk to human health? The short answer is, well, kind of yes. I assume we're all well aware of the psychological dangers of computers. This is an ancient

and well-documented phenomenon. If you use computers, after a fashion, you're going to lose your mind. So I'm going to skip right past this. Today we're focusing on the physical danger of old machine rooms. That is, how dangerous a machine room is to human health. By quote-unquote old machine rooms, I'm talking about old-school mainframe installations. These rooms have raised floors with custom cooling and special power requirements. The room itself will be stuffed with machines that take up truly staggering amounts of space, thousands of square feet.

They eat punch cards and spin acetate tapes. Real beasts. Consider for a minute just what kind of materials we're dealing with here. By that I mean physical material. An IBM mainframe installation of this era, and we're going to be in the 50s and 60s, was backed by huge amounts of media. We're talking entire rooms or even storage facilities

just for punch cards. Those cards are, of course, paper. The newer storage media of the time was tape. Despite early metallic media produced by EMCC, magnetic tapes end up being universally made from plastics. These tapes aren't just flammable. When burned, they can release toxic gases, so it'll be really smart to avoid fires and machine rooms at all costs. Let me go on a completely unrelated tangent. Have you ever seen the terminal stations used in sage installations. These were big interactive radar displays that IBM built for a massive missile defense network. The terminal desktop has it built an ashtray, you know,

so you can smoke while you operate a computer. There are actually quite a few of these old sage terminals preserved in museums, and you can literally walk up and see the ashtray sitting right there tucked away, even with a little removable holder so you can dump out the ashes. But let's say you're not working in the sage system. That's fine. IBM also handed out branded ash trays to their clients. So if your machine didn't have one, you can make it due. And this is kind of my favorite part. If you look at publicity photos of operating consoles, usually there's this desk-shaped space that has the console built into it. In publicity shots or official photos,

the desk will be empty. There might be a punch card or a manual, but they clean it off. But you can find candid photos of people running computers from back in the day, and some of them have ashtrays, inactive use, sitting on the desk,

right next to the computer in their flammable medium. That could, perhaps, pose a bit of a fire risk. Now, that's not to mention the actual computer equipment itself. Old school machines may have been electrical, but they had electromechanical I.O. devices. Printers, punch card equipment, and even tapes had moving parts. Those parts had to be oiled and greased to remain in good condition. But you don't actually need a computer to start a fire.

It can happen due to more old school problems. On July 2nd, 1959, around 10 a.m., a fire started inside the Pentagon. It happened in the machine room used by the Air Force Statistical Division. The story is described in a pile of articles in the Evening Star, but Fire in America by Paul Lyons gives a more succinct rundown. I'm using both sources here. The Statistics Division had a few things of note in its machine room. The first was a pile of IBM hardware.

Reporting says three mainframes, which I believe were three 704s. They were on a raised floor. That floor was made out of plywood with an air gap below it. It was full of who knows what. There's actually a lot of documented issues keeping those air gaps clean of debris. That raised floor provided a space for airflow and also an area to route high-voltage wires and data connection wires from component to components. The room also housed a so-called tape vault. Reporting doesn't explain what the vault was made out of.

I don't think it's metal construction, though. Why? Well, I have my reasons. You see, the fire actually started in this vault and then spread to the rest of the room. It would be odd for a fire to jump from a contained, sealed metal vault to the rest of the insulation. So I think the quote-unquote vault was probably more like a closet. There are a few theories on what I actually sparked the fire. Both point towards the ceiling. The room had a drop ceiling with acoustic foam tiling on it. There was either a faulty wire in the drop ceiling or an incandescent bulb got a little too hot, too close to the ceiling. That lit a tile, and the burning tile then fell and lit the pile of acetate tapes. From there, things escalated. The entire machine room went up in a blaze. It would take 34 minutes

for fire crews to be called, and longer for firefighters to actually get to the scene. What they found was a disaster. Accounts described firefighters hosing down these piles of tape, thinking the fire was out, only to watch the tape burst back into flames. As Earl Dodson, one firefighter on the scene, described it, quote, the trouble was, we'd put out part of the fire and then find it it started all over again. Film was stacked up high, and it sure burns stubbornly. We started ahead feeling pretty good after putting out the fire in one room. By this time, without realizing it, I was spraying from a kneeling position. Water on the floor was so. so hot you could feel it through your boots, end quote. Now, I actually have a bit of a theory

about this phenomenon. A fire needs three things, heat, fuel, and oxygen. Water extinguishes fires by collapsing that fire pyramid. It smothers out oxygen and it draws away heat. But if the water pulling on the floor was so hot you could feel it through your boots, then there's probably too much heat for the water to effectively draw it away. A contributing factor here, and part of my fan theory, is off-gassing. As certain materials burn or are heated up, they release flammable gases. A very common material does this. That material is wood. You can heat up wood in a can and then ignite vapor that pours out of it. I think something similar must have been happening with the tapes. I say think and not know, because try as I might, I can't find the precise chemical formulation of IBM tape in this

period. If you happen to be an old IBM employee and you know the chemical formulation, please let me know. It could answer some lingering questions I have. Anyway, there is another huge hazard of play here. Machine operators at the Pentagon had fled the scene so quickly, and the fire had spread so uncontrollably that they were unable to shut off power to the computers. Now, that may sound like a small issue, but I assure you, it was not. Mainframes of this era drew huge amounts of power. We're talking kilowatts. So this wasn't just a wall plug. There would have been actual high voltage, high-amp-ridge wiring going into the mainframe room. As water pooled, there was a very real,

risk of electrocution. There are no reports of first responders getting zapped, but that was a present danger. The lack of injury probably just came down to blind luck, a matter of where water pooled, how the raised floor drained, and what wires melted first. Ventilation was the other risk here. Machine rooms had forced air conditioning. That was required to be running whenever the computer was on because old machines got hot. If staff weren't able to hit the power switch, I can only assume that the fans were still drawing in cool air as the fire started. That would have quickly turned the machine room into a blast furnace. By the time power lines melted, the fire would have been burning hot enough to draw its own air in from the provided ventilation shafts.

Fire represented a very real and a very well-known danger for computer rooms. No one died in the 1959 Pentagon fire, but 30 people were hospitalized. It caused $6 million in damages to computer hardware alone. IBM literally told the Pentagon to just scrap the damaged machines. My report for this episode, computer abuses, points out that federal installations were not prepared for fire. To quote, of the 18 locations we visited in the United States,

three had only portable fire extinguishers available for firefighting protection. Also, one overseas location did not even have any fire extinguishers available for firefighting operations, end quote. The Pentagon got a bad mark in this department. They had no fire suppression equipment in that machine room.

What we have here is horror. Very expensive equipment is sitting next to media that's very flammable and dangerous to human health if ignited. So you kind of need to have a plan and equipment for dealing with a fire. Not all of these machine rooms had that. A somewhat similar disaster would play out in 1972 at IBM's Program Information Departments in New York. In that September, something started burning inside the facility, which was filled with acetate tape. It took 12 hours for firefighters to get the blaze under control. We have less detail about this fire.

What we do know is that it burned hot and destroyed just about everything in its path. Luckily, IBM had safety measures in place. Some tapes were kept in sealed metal vaults with CO2 fire suppression systems. but tapes, cards, offices, and computers outside of those vaults were toast. There's also been the suggestion that this fire was arson, but I haven't seen anything to back that up. Contemporary news articles just say that a source was never found. Flooding represents a very different risk.

It's less a health hazard and more just a hazard to computers. So check this out. Machines back in the day were heavy, like really, really heavy, so heavy that machine rooms often had to be put on ground floors or in basements. Upper floors weren't always strong enough to handle the hardware. As a result, early computers were often at risk of flooding, but like I said, that's less a death trap and more a danger to machines. Okay, so I think it's time that I address one of my larger areas of speculation.

That is, of course, mercury delay lines. I've joked a lot about how those are theoretically dangerous, but I haven't done my research. I am a hack and also a fraud. Let me try to correct that. Here's the basic idea. A mercury delay line is a long tube filled with mercury. acoustic waves are bounced from one end to the other end of the tube. Those wave fronts are used to store binary data.

For this to work, three things are crucial. Thing one, the mercury needs to be pure, needs to be free from contamination. Thing two, the mercury needs to be heated. That's usually to around 150 degrees Fahrenheit or some degrees Celsius. And three, the tube needs to remain sealed. These conditions make it so that a wave will travel through the mercury medium at a well-defined speed. This also sets up a possible disaster. The most clear hazard is the mercury itself, but even that is a little tricky.

For this, I'm using two main sources. One of my hiking buddies that works as a safety coordinator at a factory, and Mrs. Advent of Computing, who works in primary care. When reached for comments about large-scale mercury exposure, both of them said, Oh, dear God, no, please prevent that from happening. Mercury becomes dangerous when it enters your body. Liquid mercury can't do that unless you do something exceedingly stupid, like swallowing it. But hey, I don't think anyone in history has ever consumed mercury.

They'd have to, I don't know, think that it had some kind of medical benefit or something. Anyway, the real dangers are mercury salts and mercury vapor. Mercury compounds are often more soluble than metallic mercury, so they get absorbed by the body more easily. Mercury vapor? Well, you can inhale that. And your lungs happen to be very deep in your body. Technically, mercury has a pretty high boiling point,

just shy of 700 degrees Fahrenheit, but any liquid will put off vapor while it's below, its boiling point. That's why a cup of coffee will steam, even if it's not at a rolling boil. Liquid mercury does the same thing, its vapors just aren't quite as visible. That makes exposure to liquid mercury pretty dangerous. If it's just incidental exposure, then you're likely fine. Long-term exposure is what will really get you. Mercury isn't excreted from the human body very well, so it builds up over time. It bioacumia. and mercury poisoning is nasty. It causes a host of issues with the body's nerves,

from tremors to mood changes, issues breathing, to breakdown of the skin and tissues. This is why when I bring up mercury delay lines, I usually tag on the possible danger. But how present was that danger? Well, that's actually very difficult and interesting to track down. So, very few computers, actually used mercury delay lines. The technology was pretty quickly replaced with magnetic drums or core memory or even CRT-based memories. Most mercury-based computers were early one-off machines, like Edzac, Edvac, or Cizirac. Since these were lab-built wonders, the risks here are different. These computers were made by their operators and maintained by their operators in most cases.

One point here that I often forget is that one-off machines were constantly upgraded. The edsac that first crunched numbers was very different physically than the edsack that was decommissioned years and years later. So folk were in the internals of these machines very often. Delay lines prove to be annoying and fiddly components. One account comes from Cizirac, that's spelled C-S-I-R-A-C. This is courtesy of the museum's Victoria Collection. That computer had contamination issues with its memory.

Its mercury sat in long steel tubes. Over time, compounds from the steel would leach into the mercury. That mercury is no longer. pure, so it has different wave propagation properties. That means all the timing would fall out of sync. The only solution was to take out the tubes, drain them, clean them, and fill them with fresh mercury. This operation was done in a physics workshop.

There was no fume hood, no modern protection. Just a math nerd with a large vat of mercury on a glass-blowing table that had a drain spout on one end. That's some pretty casual exposure to possibly dangerous vapor. And especially with the fact that this was a recurring problem, that would have ended up being a lot of cumulative exposure to mercury vapor. There are some other hints of casual exposure in the literature. I think my favorite comes from Herbert Norris, a technician who worked on Edzac. Quote, what would health and safety say now to the mercury globules in the floorboards, end quote. Note that he doesn't say, oh yeah, mercury leaked sometimes.

Nah, he's very casual about it. At the time, mercury exposure wasn't known as a huge danger, so you won't find accounts from the period where folk talk about it like it was a danger. It's more, in retrospect, operators being like, oh, yeah, that probably wasn't the best, huh? What makes this ED-ZAC thing so funny to me is that that computer is being rebuilt from scratch. It's happening at the National Museum of Computing in England.

I got to meet one of the volunteers that was working on the project recently, and we got talking about memory. The new EDZAC uses another form of memory because of health and safety concerns. Maintenance and construction is when mercury becomes a clear hazard. That's when folk are getting exposed to it. But so far, I've only mentioned unique machines. What about mass market computers? Well, the most produced mercury machine was probably Univac 1. That computer used a whole lot of mercury for its memory.

The memory system designed for Univac was truly complicated. I wouldn't say sophisticated, but boy, there's a lot to it. Its mercury was actually housed in special tubes. These had a hole drilled in one side, right in the center of the pickup crystal, that hole allowed mercury to flow out into a separate expansion chamber. That was needed because of the temperatures involved. As mercury heats up, it expands. That's actually how old-timey thermometers work. For the memory system to function, mercury needed to be kept at a correct volume and a correct temperature.

so you kind of need an expansion chamber to make it more reliable. Sensors in the tube checked how much the mercury expanded or contracted during operation. That data was used to control sets of heaters, but there was a danger of the mercury over-expanding or a sensor failing. From the maintenance manual, quote, If the heat does not cut off when it should, the mercury continues to expand. If it expands far enough to connect the second and third contact points, it completes the circuit that applies power to the overheat alarm line.

That's right. The danger of expandable memory was such that Univac had a dedicated alarm. You know, for a memory thermal runaway. Also worth noting, these alarms had lights, and they had bells that would rain. So you could have a very real situation where the Univac goes into meltdown and alarm bells start going off.

To look at this another way, this was a known problem, or at least it was something that engineers at EMCC, the company that made Univac, were afraid of. Even just daily wear and tear was an issue. Alan Ryder, an engineer who, who worked on Univac number 10 describes mercury leaks while running his machine.

Every day, the Univac had to be brought up to running temperature. The vacuum tubes and mercury tanks had to heat up. That daily thermal cycling puts stress on the metal tubes, their gaskets, and the crystal detectors at each end of a mercury delay line. To quote, Once in a while, a crystal would crack causing a mercury leak, and that was a real mess, end quote. That would expose the machine room to hot mercury.

Vapers would waft from the cabinet into the air. I can't find how often these kinds of leaks happened, but over time this could be a very real danger. Especially if an operator is using the term once in a while, that leads me to believe it's not a one-off oddity. Another ever-present danger was heat. If a computer gets too hot, then it'll stop functioning. The same is true of folk.

Overheating was a known issue for old machines. In fact, it was a worry as far back as the Inniac days. From that venerable machines manual, quote, If Inniac shuts down from overheating, do not try to restart. Call maintenance personnel. If any panel runs consistently much hotter than the others, do the same. Leave, call for help. There's nothing you can do. Well, perhaps stressful, this doesn't sound particularly dangerous. I'm taking this down this path because there's one story that I just have to

share. It involves a hot Univac, wildlife, and a confused technician. One of the Univacs, specifically number 14, installed in Gary, Indiana, went haywire in 1961. That machine had been delivered to a U.S. Steel office a few years prior. According to writer, this machine had a special setup. It was liquid cooled. Water flowed through cooling channels to keep the Univac running at the right temperature. That water had to come from somewhere. U.S. Steel pulled it straight from the tap. Apparently they used a municipal water supply to provide the precious cooling fluid. Gary, Indiana, at the time, pulled their municipal water straight from Lake Michigan.

The setup worked fine for four whole years, but then something went wrong, from the AP, quote, scientists at the Armour Research Foundation thought something was fishy when their $3 million electric brain went on the blank, end quote. their Univac was overheating. Imagine the cacophony of alarm bells and blinking lights all over the operator's desk. That's a bad state of affairs for a number of reasons. As I said, it takes time for a Univac to come up to temperature, about half an hour. If you shut it down and it cools off too much, you have to preheat the machine all over again. That also adds more stress since each extra cycle causes components to thermally expand and contract.

So, it's not the best state of affairs for a computer. The machine was eventually brought down and torn apart. The issue was tracked down to the liquid cooling system. Turns out that a number of small fish had somehow made it through the tap and into the computer's tubes. Not a direct hazard to human life, I'll grant you that, but definitely a hazard for the wayward fish. Thus, we reached the end of today's tale. Were old machine rooms death traps? In a way, yes.

The risk of mercury exposure has, I think, been overstated, at least by the numbers. Few folk were in the wrong place at the wrong time for that. But some early operators, and especially researchers, would have inhaled a lot of mercury vapor, perhaps dangerous amounts. The real risk, which I didn't expect, was, fire? Machine rooms were full of dangerously flammable materials. Forced air ventilation could provide enough oxygen to cause disaster. Few were prepared for such an event. I have two examples here of catastrophic fires in and around machine rooms. I'm certain there were more small fires or near misses that weren't well recorded. There is a secret third risk in these early computer installations.

That, however, will come up later this month. Until then, thanks for listening to Advent of Computing. If you like the show, you can support it on Patreon. By going to advent ofcomputing.com, you can find a link that says support the show and go over and pitch me a couple bucks. You can also listen to the official after show, adjunct of computing, wherever you're listening to this podcast right now. I'll be back in a week with the next part of Spooktober 26.

Until then, have a great rest of your day.