Advent of Computing - Episode 141 - Computer Ruins Grocer

Episode Date: October 6, 2024

In 1962 Food Center Wholesale Grocers Inc installed a new IBM 305 RAMAC. That's when things started to go wrong. The faulty machine seemed to have a mind of it's own, and would spread chaos to grocery stores all around Boston. Selected Sources: https://archive.org/details/computerinsecuri0000norm - Computer Insecurity https://bitsavers.computerhistory.org/magazines/Computers_And_Automation/196805.pdf - Computers and Automation article https://archive.org/embed/sim_computerworld_january-01-08-1969_3_1 - Computerworld

Case number 62.010, Berserk Computer at Wholesale Grocers. Causing a great deal of amusement and some red faces in the modern world of computerization is the story of one that went berserk and which resulted in the award of damages amounting to $53,000 to a wholesale grocer in Boston, Massachusetts. Computer Insecurity, 1983 Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 141, Computer Ruins Grocer. We've finally reached spook month 2024. If you're new to the show, then let me explain. Every October, I theme the podcast around spooky, creepy, and

frustrating stories from computing's past. The caveat here is that, in general, computers aren't actually scary. But man, can they be frustrating and confounding. In past years, we've talked viruses, email spam, horror games, and debugging. This year, we're doing something a little different on the podcast. As you are hearing this, I'm actually on vacation. I was convinced to leave the central office, if you can actually believe it. In order to keep the show going, I decided that instead of working up two big episodes, I'm going to produce four shorter stories. This means I can streamline production and get a few

banked for my trip. It also means I can talk about some stories that normally wouldn't have enough source material for a full episode. The results, I hope, will be some lighthearted fun for all parties involved. To kick things off, I'm going to be sharing the story of a computer program gone bad, and the resulting battle between the machine's manufacturer and its unwitting victim. Sounds spicy, doesn't it? I first heard this story as a case study in the wonderful book Computer Insecurity by Adrian R.D. Norman, published in 1983. I highly, highly recommend tracking down a copy if you can. I had to scrounge around quite a bit when I found my copy a number

of years ago, but now it's published on the Internet Archive, so it's really easy to find an e-print version. The book is about some of the first recorded computer crimes, mishaps, and litigation. It attempts to build a framework for talking about different types of digital incidents and tracking down their origins, and in some cases, their motives. It has a listing of case studies broken up and organized by all kinds of categories, with sources for everything. Did I say I highly recommend this book? Well, I do. It's kind of bait for me. Today's story is one of the earliest case studies in the book. It's about an incident that led to a court battle against none other than IBM itself. And it all goes back to one of the classic digital horror

stories, a bug. On October 5th, 1959, Food Center Wholesale Grocers, Inc. started construction of a massive warehouse in Boston. The company acted as a middleman, moving groceries from larger suppliers to actual grocery stores and restaurants. Basically, it's a big logistics service for anything you might want to eat. They had formed sometime earlier in the 1950s and were continuing to expand at a rapid pace. Business would continue to boom after they moved into their new warehouse. The food center was also a very modern operation. By 1960, they were already hiring computer and punch card operators. We're talking about a digital outfit. Now, it's not entirely clear what computer the

food center was running in this early period. They had become an IBM customer all the way back in 1954, probably around when they were established, and they had operated tabulators and sorters and the like for years. They may have been running a 650 or something similar at this point, but that's purely my speculation based off the time frame and some job listings for IBM computer operators. In 1962, the Food Center made a jump to a new machine, and this one we have documentation for. It was the IBM RAMAC.

I'm sure this decision was spurred on by some slick-talking men in blue suits. That's just the natural order of these things, after all. But shockingly, this would be one of the instances where buying IBM led to a disaster. You see, this particular RAMAC, well, it had a mind of its own. I'm reconstructing this story from a number of sources. It comes to us partly from Computer Insecurity, another book called User's Guide to Computer Crime, a few articles in Computers and Automation, and in Computer World. I'll link my sources in the description. But the one name you need to know, the key player, is Joe Rodman, co-owner of FoodCenter,

and usually the person interviewed for these articles. The 305 RAMAC was, for the time, a state-of-the-art machine. It was part of this dead-end lineage of computers. Essentially, it was designed as a direct replacement for earlier punch card machines. You could program it, but it could also be configured using jumper cables just like a tabulator. Its key feature, however, was the hard drive. The RAMAC was built around a stack of giant platters waiting to store your important accounting and actuarial data. The setup, in theory, could automate away all of your headaches.

All of the bureaucracy could be moved from paper and people to a computer. For the food center, this would mean easier inventory and accounting. That is, if it actually worked. Rodman's RAMAC didn't even want to turn on. That, on its own, would have been horrifying to witness. You didn't just order a computer and wait at the mailbox back in the day. The food center would have spent months working and negotiating with IBM directly. Contracts had to be worked out and signed. An entire room had to be outfitted for the machine. Staff had to either be hired or trained with official IBM courses. Even physical installation

would have been a huge undertaking. We're talking about a forklift just to move the hard drive. Food Center's warehouse must have been crawling with technicians for days. When the moment came to flip the switch, Rodman decided to make a ceremony of it, Food Center's warehouse must have been crawling with technicians for days. When the moment came to flip the switch, Rodman decided to make a ceremony of it. Why wouldn't you? But all that work led to nothing. The RAMAC refused to even turn on. Technicians were summoned back to Food Center, and after a while, the RAMAC did spark to life. But this wasn't the

end of the computer's troubles. This machine just wouldn't play along. According to one of the Food Center's customers, via reporting in Computers and Automation, quote, it was continuous grief. We would get 5, 10, or 20 times the amount of goods we ordered. We had no place to put it all, so we had to ship it back. End quote. It seems that the RAMX programming had gone haywire. The food center had set up their computer to handle inventory, accounting, and orders. It spit out what food to send where and when. It calculated how much each customer owed the company. It also calculated how much food was held in the food center's warehouse. Somehow, the program didn't like

to get all the details correct. Reporting tells that the RAMAC would send out totally incorrect inventory numbers. Too much food would be sent out to customers, or conversely, orders would be dropped right off the disc. Customers were being sent wildly inflated bills, given wild deals, or receiving a ton of cabbages and no bill at all. It was chaos, and it was expensive chaos. According to Joe, quote, that computer almost put us out of business. According to Joe, It had been planned as a new linchpin for the company, and the machine had totally flopped.

Worse, it had flopped in a pretty unpredictable way. It would be one thing if the RAMAC had never turned on, if it just stayed broken. Then you just don't have a computer. Oh well. You keep living with punch cards, and the IBM technicians keep scratching their heads, but everything's fine at the end of the day. You can move on.

But this RAMAC almost worked. It created invoices, but they weren't always correct. It dispatched shipping manifests that were sometimes fine. That degree of inaccuracy came at a huge cost. I don't have access to the contract, but I can extrapolate some details from a few later documents we'll get to. This is back in the era before antitrust really hit IBM, so we're talking about Big Blue while they were fully in their powers. You didn't just buy one of their computers, you leased it by the month. This particular RAMAC ended up being valued at some $2,080 a month. Every month the computer wasn't working, the food center was losing,

at minimum, that lease fee. Point is, whatever bug had taken root in this RAMAC was costing a lot. But in some ways, this whole lease agreement should have helped out. IBM's old contracts were full service. If you bought IBM, you were inside the IBM system. For their fee, a leasee received hardware, software, and full support. Blue-suited technicians installed RAMAC and also trained Food Center employees on its operation. Crucially, IBM wrote the custom software that was supposed to make RAMAC run the Food Center's whole operation. This was just how IBM operated back in the day before antitrust actions. Everything was bundled.

When the food center decided to upgrade to a RAMAC, their local IBM rep would have asked them what kind of software they needed and would have priced their contract accordingly. In many circumstances, that's a big plus, right? You buy into IBM and you're part of this big blue family. All you need is some money and a problem a computer can solve. Sometimes you don't even need the second thing. The food center luckily had both, but they encountered the downside of the bundle. When the issue came up, the food center could only rely on IBM to fix this. Food Center could only rely on IBM to fix this. And this is where the stories start to diverge.

According to IBM, a programmer was dispatched and the program was fixed within two weeks. But the Food Center must have missed that memo, since they refused to pay their lease for four whole months. This disagreement eventually led to, well, some issues. But either way, it seems that the RAMAC at Food Center was somehow to blame. Technical details here are scarce. What we do know is that an IBM programmer tried to reproduce the errors on another RAMAC at a different location, and the food center's program ran without issue. There was some kind of improbable combination of hardware and software conspiring against wholesale food deliveries. This specific RAMAC was somehow special, somehow cursed. That may make the modern mind real, right? One RAMAC should be the same as any other.

Well, not necessarily. These are early mainframes we're talking about. Installations were somewhat bespoke in this period. It's possible there was just some quirk in how the food center's RAMAC was set up. Or maybe the install was botched. in how the food center's RAMAC was set up. Or maybe the install was botched. Whatever the reason, there was something special and something a little bit broken about this RAMAC.

As I said, the timeline is a little contentious. Some sources claim that the issue was resolved in two weeks. I've even seen certain sources say it took six months. So what's the truth of the matter? Well, I think it may be somewhere in the middle. My evidence for this is a court case. The Food Center claimed that IBM's faulty code had cost them dearly. IBM counterclaimed that the Food Center had refused to pay their computer rent

for some four months during this whole RAMAC debacle. pay their computer rent for some four months during this whole RAMAC debacle. It's that claim that makes me believe issues persisted for a number of months rather than weeks. Whatever the case, Food Center ended up making the first move, filing suit in 1963. The company sued IBM for damages, with IBM counterclaiming back rent. The issue wasn't resolved until 1968. Long trials are kind of a theme for IBM. A jury ruled in Food Center's favor, awarding them $53,000 in damages. The decision hinged on another order of horrors, contract law. The Food Center argued, essentially, that the RAMAC was under warranty. When it didn't work, it cost Food Center very real financial damages. That failure was ruled a violation of warranty. This would be one of the first legal cases over faulty software, period.

IBM's counter-argument was that no such warranty was ever signed. This would fail, but it's important to consider. IBM argued that there was no new contract for the RAMAC. Instead, the new computer was still subject to the first contract that FoodCenter had signed with IBM, all the way back in 1954, almost 10 years before the lawsuit. That contract just said that IBM would supply accounting machines. And RAMAC was an accounting machine. Thus, presto chango, IBM could say RAMAC was actually covered by a contract that had no mention of warranty or fixing any computer things at all. I think what may have tipped the scale towards the food center is that IBM kind of got bit by their own sale tactics.

Joe Rodman admitted there was no single contract for this new RAMAC. The deal had been worked out over a series of meetings and ongoing conversations with IBM. This would have been with food center's very own personal blue-suited representative. There were some written components of that agreement, and there were some verbal assurances. It sounds to me like their rep simply guaranteed the new RAM Act would work, that it would solve anything the FoodCenter wanted fixed, and that no one ever got fired for buying IBM. But this wasn't a total victory for the food center. It was ruled that they did, in fact, owe IBM rent. At least in part. The jury gave food center a little discount. Only $25,000 were owed.

So when all was said and done, the food center netted less than $20,000 from the whole debacle. But apparently, that was enough to keep the food center going. In fact, there's a funny coda to the whole story. It was reported that Joe Rodman decided to stay with IBM. In 68, the same year the lawsuit was paid out, he signed a new contract for a shiny IBM System 360. So hey, maybe it really is true that no one gets fired for buying IBM. All right, that does it for the first episode of Spook Month 2024. We saw how a cursed Ramac spread chaos at grocery stores in the greater Boston area, and we encountered one of the rare cases where IBM lost a lawsuit.

All in all, I think that makes for a good start to the season. We all rely on computers, and we assume that they will work, at least in some capacity. When a PC fails, that can be annoying. But when a larger machine, when a piece of business infrastructure goes on the fritz, well, that's scary indeed. The implications of a rogue machine in the wrong place can be wide-reaching and devastating. In this case, the problem was corrected, but not before one bad RAM act could cause a whole mess of trouble. Is there a moral to this story? Maybe it's something about not relying too much on a single supplier. Maybe it's something about the dangers of monopoly. Or maybe it's just a reminder that we shouldn't trust digital circuits quite so easily.

it's just a reminder that we shouldn't trust digital circuits quite so easily. Thanks for listening to Advent of Computing. I'll be back in just one week this time with the next short part of Spook Month 2024. If you like the show, there are a few ways you can support it. If you know someone else who'd be interested in the history of computing, then please take a minute to share the show with them. You can also rate and review the show on Apple Podcasts and Spotify. If you want to support the show directly, you can do so by buying Admin of Computing merch or signing up as a patron on Patreon.

Patrons get early access to episodes, polls for the direction of the show, and bonus content. You can find links to everything at my website, adminofcomputing.com. If you have any comments or suggestions, you actually can't reach me, I'm on vacation! But I'll be back in a few weeks. And as always, have a great rest of your day.