Advent of Computing - Episode 143 - The Haunted Hard Drive

Episode Date: October 20, 2024

Have you ever felt like a computer just refuses to work? Like a machine has a mind of it's own? In 1970 a hard drive at the National Farmers Union Corp. office decided to do just that. That year it started crashing for apparently no reason. It would take 2 years and 56 crashes to sort out the problem. The ultimate solution would leave more questions than answers. Was the hard drive haunted? Or was something else at play? Selected Sources: https://archive.org/details/computercrime0000mckn/page/98/mode/2up - Computer Crime https://archive.org/details/sim_computerworld_1972-08-02_6_31/mode/1up?view=theater - Computer World article

Anyone who works a computer for a living has one deep and primal fear. The sound of a phone ringing any time after 5 p.m. That fear grows stronger the later the evening gets. A call at midnight is about as high as that stress scale goes up. Us poor industry ghouls know that a late-night call can only mean one thing. Something's gone horribly wrong, and someone has to fix it. If you're getting that call, that someone is likely you. Luckily, this is a rare event. That's partly what makes it so scary. We all have one or two

stories about a late night disaster, a weekend ruined by some bug, or maybe that one time the network went down while you were supposed to be headed to vacation. These are special occasions seared deep into the psyche of many programmers, systems administrators, and operators the world over. But what if, for some poor office, these disasters weren't special? What if they were all too routine? Imagine you had to live through 10 of these disaster calls, or 20, or even 50. That scenario was a reality for one particular office in Denver, Colorado. In two years, they experienced 56 separate incidences, all caused by the same hard disk. It took two years, they experienced 56 separate incidences, all caused by the same hard disk.

It took two years and experts from around the country to figure out just what was going wrong. Was it a curse? Was it a machine going berserk? The truth is, perhaps, more frightening than any mere bug. Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 143, The Haunted Hard Drive. Today, we're continuing our spook month 2024 coverage with a short dive into another persistent bug. We all rely on computers in our day-to-day life, so what happens when those very machines become unreliable? We already looked at one such case this month, the cursed RAMAC that almost destroyed the Food Center Wholesale Grocers Incorporated. That was a case of a software glitch. The machine ran, it just ran a little off the rails. In this episode, we're looking at

another category of problem. That is, a computer that stops working altogether. I'll be sharing with you, dear listener, the story of the National Farmer Union's cursed hard drive. In just two years, the drive short-circuited 56 times. Each event brought their machine room to a complete halt. The disruption cost them half a million dollars. But, as with most bugs, it was ironed out. The root cause was even found. And, since then, it's become the thing of stories and folklore. The lead for this episode came, once again, from Computer Insecurity. I'm telling you, it's a really good book, don't sleep on this one. The hook that I read in their case studies led me down quite the spiral of a story.

studies led me down quite the spiral of a story. There are at least two tellings that I've been able to find, and one is far more credible than the other. This episode, I'll do my best to cut to the truth of the matter and figure out just what was wrong with this seemingly cursed hard drive. Our story begins in the machine room of the National Farmer Union Corp's office in Denver, Colorado. The year is 1970. NFU was a Burroughs outfit. Specifically, they ran a B3500 mainframe, a mid-sized computer for the time. The 3500 wasn't that new of a machine, but it wasn't an antique either. We could call it a mature platform, if you will. By the time our story starts, it was a four-year-old computer. These mid-range machines were actually pretty interesting in their own right. Burroughs had designed the range specifically for running COBOL. They were even optimized on the hardware level.

So, as such, they were aimed directly at businesses looking to automate their operations. These machines were also data hounds. Brochures show B-3500s hooked up to a truly staggering array of storage devices, from tapes to punch cards to hard drives and networks. If you wanted to move bits around, burrows had you covered. Most of these storage devices were optional, save for one, the disk file, or the hard drive. A user was free to store files on there, but it was also the B3500's main store for software.

In fact, the disk file had to be used for the computer to boot, since that's where the operating system was stored. Without the disk drive, the machine was, for all intents and purposes, inert. Perhaps you can see the danger here. The drive, in its separate enclosure, represented a single point of failure. As goes the drive, so goes the system. Even once running, the drive was crucial. If the hard drive suddenly, I don't know, stopped working, then the computer couldn't load new software, couldn't swap to disk. That's a pretty common operation, so it would, once again,

render the computer inert. This isn't a specific knock against the Burroughs 3500. All computers that rely on hard drives have this point of failure. But rather, look at this as a setup for disaster. Starting in 1970, NFU's disk drive began acting weird. It started to short circuit. That's not exactly the most common failure mode for a hard drive. This is back before integrated circuits were a big factor, so we aren't dealing with microscopic wires. A short would have to actually travel a pretty good distance. And with these kinds of disk drives, well, there are about a thousand more pressing concerns before you get to a short on the list.

These old drives used huge magnetizable platters. Exposure to a magnetic field, like from a fridge magnet, would irrevocably scramble their bits. That's one huge concern. They were also very susceptible to dust and dirt. If the platter got even a smudge, your data was done-zo. Platters spun on mechanical bearings, which could be fouled up. Lubricant deep in the mechanism could dry up, or it could leak, or the magnetic head could crash

down and scrape the platter. A short circuit is, like I was saying, pretty far down on the list of fears. For a short to actually occur, two wires would have to cross, or something would have to bridge two wires. Most wires in these kinds of machines are insulated in order to prevent just such a problem. There are some edge cases where this can happen, though. Insulation can wear away if wires are moving, or a wire could get crimped up against some sharp part of the machine's case. Some aircraft in particular will run into issues where wires that go through holes and bulkheads can wiggle around and rub against the sides of the hole over a long enough period of time that can wear away insulation causing a short.

a long enough period of time that can wear away insulation causing a short. But these are kind of freak accidents. Physical damage can cause a short. Wear and tear over long time spans can cause a short. Bad manufacturing can cause a short. In all of those cases, there will be signs and evidence. What NFU saw was much less complex than those failure cases. Their disk drive just shorted out and died. And it happened again and again and again and again. A slow, creeping failure or freak accident wouldn't happen 56 times in a row. Thus, it had to be something more systemic. From contemporary reporting, we know that NFU tried a few things while troubleshooting.

This is also where we do reach a little speculation. This part is put together from a few different articles, but we don't have a first-party account. I've tried to assemble all of this into some kind of logical order, but the truth of the matter might be a little more complex or not quite in the order I've placed things. The gist here is that there had to be some recurring issue that caused this short circuit, and they were going to move heaven and earth to find it. One possibility was a power surge. Some sources claim that the NFU office was in a newer part of Denver, so there was a possibility that there could be something up with the power grid. A series of back and forths with the city and the local power company led nowhere. No one else on that part of

the grid, new though it was, reported any weird shorts or surges. If the problem wasn't coming from outside the office, then it must be from within. So NFU staff set about inspecting and replacing the electrical system. In theory, a bad circuit in wall wiring could lead to a surge or maybe a short. Why not? Maybe there was a wire that had been crimped between ceiling panels, or a loose connection. There have been some truly wild cases caused by seemingly unrelated bad wiring. But after crawling over the walls and ripping down panels, this led nowhere. It sounds like this path was proven faulty sometime after the office had been largely rewired, and then the disk drive crashed yet again. This all eventually led to direct involvement from Burroughs themselves. We're still in the leasing era, so the computer housed at NFU was owned by Burroughs. There was

also an ongoing relationship between the leaser and leasee. So when Burroughs got involved, they got involved. Technicians would have beset the machine room, but even after extensive work, the disk drive kept shorting. Burroughs technicians found nothing wrong with the machine, but it kept breaking. Each event led to between 8 or 24 hours of downtime. The costs were really adding up. That said, something was becoming clear from all of this troubleshooting. There wasn't any technical issue at play. The drive was sound. The power grid was sound.

So were the brand new wires in the walls. It had to be something more unusual. Maybe the drive was haunted. Maybe the ozone layer was just a little too thin above this one particular office. Or maybe it was sabotage. It's unclear when this final possibility was discussed. We do know that by 1972, NFU was pretty over this whole computer thing. They were seriously considering just switching to another machine. According to Computer Crime by Gerald McKnight, Burroughs convinced NFU to keep troubleshooting. It was at this point that the local police got involved.

Sabotage, it would seem, was becoming a consensus. But how do you catch a saboteur? Whoever it was had to have access to the computer. They had to have been left alone in the machine room for some amount of time, even if that was just a small window. You could enact a new rule that the machine had to be staffed by two people at all times, but the best case scenario there is you prevent further sabotage. It would be better to catch the crook in the act and figure out just exactly what's going on. At this point, it's still not even clear how the machine is being shorted. The new team of NFU, Burroughs, and the local cops decided to take a radical step. They did something that would make any hacker's blood run cold.

They installed CCTV cameras in the machine room, and they set up an observation post. Security guards would monitor operations remotely as the machine was used throughout the day and night. It's noted that the system came at great expense, but it was an investment that paid off. It only took three days to catch the saboteur in the act. And this is where the story diverges into two main tellings. One is chronicled in the story of Albert the Saboteur. From what I've read, it appears that this version of the story shows up in the 1990s, making its way into computer security textbooks. It goes something like this.

Years and years ago, NFU hired a computer operator named Albert. He worked the night shift alone for many an uneventful night. All seemed well, all seemed in order. The shift suited him, at first. But eventually, something changed. Albert started to get lonely holed up in the cool machine room night after night, only encountering other lifeforms during shift changes. Or, well, in the rare occasion that something went wrong with the mainframe. This built and built until Albert snapped. He had seen a disk crash happen before on the night shift, unaided.

Albert would pick up a phone, make a call, and report the disaster. Everyone would rush into the office. The lonely night would be over. As an operator, Albert also knew just how fragile one of these machines could be. So he decided he'd break the computer, phone in the crash, and sit back while his coworkers streamed into work. Thus, a lonely night was averted, and Albert would be a hero for reporting a crash in real time. The trick was simple. Albert only had to open up the disk drive's door, find a few contacts on an exposed circuit board, and bridge the gap with his car keys. Zip zap, and the disc would short out, crashing the entire B3500.

Some even add the flair that Albert would call in the crash, then go down the street to grab coffee and donuts for the inbound team. That would work 56 times before he was caught in the act by the CCTV camera. That's a fine story, but it's not entirely factual. There's another spate of reporting from the early 1970s, much closer to the event that paints a slightly different picture. For this, I'm pulling from a number of reports, but primarily computer crime. McKnight claims to have talked with a number of people involved in the case and subsequent trial,

so he gives us the most detail out of any source. The true story actually has a full name to work with. The saboteur was named Keith Noreen. He was an unassuming 20-something computer technician, and he'd worked at NFU for a number of years. It's not clear if he worked the night shift, but at least the first crash happened at night. I think it's more likely he just worked in the machine room and was occasionally left alone. One day, something went a little screwy with Noreen.

After his arrest, he described it as a quote-unquote overpowering urge to destroy the computer. His first attempt didn't exactly work. McKnight claims Noreen tried to crash the drive once and failed. But the second time, he figured out the trick. He could open up the hard drive cabinet, find this one exposed circuit board, and bridge two contacts with his car keys. In a matter of seconds, the machine would grind to a halt, but it was never fully destroyed. The B3500 would always spring back to life. Sometimes it took eight hours of work, sometimes a whole day, but the computer wouldn't die completely. hours of work, sometimes a whole day, but the computer wouldn't die completely. The urge didn't drive him to totally destroy the machine. He didn't take a hammer to the platters, strip out

circuit boards, or bring in a hose. But he did short out the disk drive. He did bring down the machine, ruining days upon days of work. Noreen was caught in the act, all recorded on CCTV. He was confronted by police, admitted to what he was doing, even did a little demonstration, and was arrested on the spot. The charge was criminal mischief, aka vandalism. All told, he had cost NFU half a million dollars and two years of chaos. He would end up facing up to a year in prison. The true story, the case of Keith Noreen, isn't nearly as neat and tidy as Albert the Saboteur. There isn't some tidy conclusion that reveals everything.

There's no clear motive. Noreen isn't lonely and looking for some technicians to spice up his nights. We aren't even sure if he worked night shifts. He isn't some political dissident staging a protest or an angry employee getting back at his boss. Some sources, including Computer Crime, claim that Noreen had a history of mental illness. That may be true, but I think reducing it to that misses a point. I'd argue that any of us could be a Keith Noreen. Look at it from the other side. As we've established, a phone call late at night is the worst fear of many programmers and IT professionals. If this really was a night shift story,

then the employees of NFU came face to face with that fear 56 times in the span of two years. I know I felt like throwing my laptop out the window after just one late night call. I can't imagine how you even begin to cope with that kind of frustration and disruption night after night after night. There's something unnatural about computers, and about all the corporate artifice that's sprung up around them. It manages to twist us practitioners into these stressful and, in many cases, futile exercises. Does a hard drive crash really need to be fixed at midnight? Maybe not, but someone at your company who gets paid more than you will think so. After enough of those late night calls, you might start thinking of new ways to escape the cycle.

And let's say no one's looking. There aren't cameras in, well, in this corner of the data center yet. You see some exposed circuits, a cabinet door hung open, and you hear the jangle of your car keys in your pocket. I think that urge could get to just about any of us. Alright, that does it for the story of the haunted hard drive, or Albert the Saboteur, or the story of Keith Noreen. I've seen a number of morals to this story. The most common recommendation is for every machine room in the country to buy and install a CCTV system and employ security professionals. Or maybe to vet job candidates more thoroughly.

Or perhaps, my favorite, the computers should be built to be more physically secure from outside tampering. You really have to seal those machines up to keep them fresh, after all. What I haven't seen is the story being used as a cautionary tale about how computers can become a psychic hazard to their operators. Maybe the work environment had nothing to do with Noreen's actions. But then again, nothing really happens in a vacuum. At the end of the day, computers might not be haunted, but they may be able to lay a curse on any nearby practitioner. Thanks for listening to Advent of Computing.

I'll be back in one week this time with the final episode of Spook Month 2024. And hey, if you like the show, there are a few ways you can support it. If you know anyone else who is interested in the history of computing, then please take a minute to share the show with them. You can also rate and review the podcast on Apple Podcasts and Spotify. If you want to support the show directly, you can do so by buying merch or supporting the show on Patreon. Patrons get access to early episodes, polls for the direction of the show, and bonus content. You can find links to everything on my website, adventofcomputing.com.

If you want to get in touch with me, then fat chance! I'm on vacation still! I'm free for another week! And as always, have a great rest of your day.