The minicomputer industry was created at Ken Olsen’s company, Digital Equipment Corporation. Digital, also known as DEC (pronounced “deck”), dominated the industry for its entire 40-year existence.
Data General was started by former DEC engineers, most notably Ed de Castro, who was CEO for its first twenty years. He was followed by Ronald Skates for DG’s final ten years.
My father worked at DG for almost ten years. My first exposure to the company was in 1976, when visiting Dad there during my junior year of college.
Five years after that visit to Westborough, I was starting a new job and working on both DEC and DG systems. That was the same year Tracy Kidder’s Pulitzer Prize winning book The Soul of a New Machine appeared. It told the story of how DG developed its 32-bit system, called the MV-series. I bought a copy as soon as it was out in paperback.
DG was a perennially distant second cousin to DEC in every way, right down to its circuit boards. Where DEC’s boards were beautifully fabricated, DG’s often had patch wires with solder splash. With the exception of a couple guys I worked with, DG’s field engineers didn’t have the same level of training and skill as DEC’s FE’s. They certainly weren’t as well equipped.
An unexpected and pleasant assignment I once had was assisting de Castro’s girlfriend Eileen (later his second wife) for a couple of days. Closer to my age than to Ed’s, she was bright, personable and unpretentious. My immediate thought was she must have had a marketing background. I helped her get an early DG laptop computer up and running and we put it through its paces for a presentation she was preparing.
Every so often I have checked to see if de Castro was still alive. During my recovery from cancer treatments I missed spotting his obituary. (I’m saddened to see that Eileen passed away a year ago. She was only three months older than myself, and I was right about her marketing background.)
https://www.chiampafuneralhome.com/obituaries/Edson-Donald-De-Castro?obId=33029648
The nadir of my association with DG came in 1994. The DG sales rep for my employer, a guy named Peter, tried to get me fired. Five years later he had to scramble to stay on board after EMC took over. Here is the long, painful story as was told on LinkedIn, without mentioning DG.
Part 8a: Customers were reporting terminal server crashes, followed by reboots. A couple of years earlier, there had been a bug in our terminal server code, requiring an “all hands on deck” effort by the support staff to install an update across a significant portion of the customer base. That memory was still fresh when the new problem appeared. So although the failures were sporadic, and happening in limited clusters, we weren’t going to take any chances.
The terminal server software was checked carefully, and the code was solid. The lead operating system developer responsible for the code told me he suspected a hardware problem. One of the affected customers he’d been looking at remotely was local to my office, and he asked me to check it out. So I called my contact there, said I was on my way, and half an hour later I arrived at the hospital.
I stood in front of one of the terminal servers that had the failure. Watching the status lights it didn’t take long to see what was happening. The lights went dark, then they flashed and the terminal server rebooted, as if the reset button had been pressed. To me it looked like a hardware problem, as the system developer had suspected.
A loose power plug could cause it to happen, but the cord was held in place properly with a retaining clip. I pulled the terminal server off its shelf and removed the cover. The wires coming from the power supply were attached to the circuit board with the same sort of slide-on clips that are used inside of loudspeakers. I wiggled one of the wires and could see the clip was very loose. The terminal server lost power and rebooted. I called the system developer and said, “You’re not going to believe this.” Once again, a weak connection was the cause of all the trouble.
I wrote down the serial numbers for some of the terminal servers, and back at the office I forwarded those to the manufacturer. The upshot was that another Field Change Order was generated, like the one from a few years before to modify the Ethernet AUI plugs. The problem was limited to a relatively small number of units from a particular production run, and my recollection is the fix was to solder the clips onto the circuit board contacts.
Having been through the Field Change Order routine before with the same technology partner, as far as I was concerned that was the end of it. Except it wasn’t.
Part 8b: It was an extremely busy time. One of the members of my team told me at the end of a workday, “You took forty calls today! I counted.” A call came in from a customer who said he was having terminal server trouble, “and I’ve been told you’re the guy to talk to.”
He sounded frustrated and agitated. Although the group responsible for system-level support had been informed about the hardware vendor’s field change order, I didn’t bother asking if he had spoken with them. By then I’d worked on thousands of technical problems, with hundreds of customers. I knew that some of them would call my installation group as well as the support group, just to see if they got the same answer. From the tone of his voice, the best thing for me to do was to help him without delay.
It wasn’t up to us to distribute a notice to customers about the field change order for the terminal servers. It was the responsibility of the manufacturer. I didn’t know if this particular customer was paying for field service from the vendor directly, or if he had hired one of the independent shops that were cropping up in the waning days of minicomputers. I wasn’t going to get in the middle of whatever service contract he had signed. What I knew was, based on his answers to my questions he definitely had some of the terminal servers with the shaky power supply connectors.
He explained his field engineer had been onsite, but couldn’t figure out the problem. I explained that he should tell his field engineer to see Field Change Order #42. (I remember the number for a reason that Science Fiction fans will know.) He demanded to know why his field engineer didn’t know about the change order. I told him I had no idea, but telling his FE about FCO #42 was the next step for him to take. He sounded somewhat relieved. I found out later the servers got fixed, but along with the good news something bad hit the fan.
Part 8c: My boss came up to my desk and said his boss, a senior VP, wanted to see me right away, but he didn’t know why. That couldn’t be good, and it wasn’t.
The VP handed me a letter and told me to read it. The letterhead was from the minicomputer vendor of the terminal servers with the power supply problem I had uncovered. (The server was a modified model from an OEM.) The letter was signed by their sales representative for our account. Someone who I’d worked with for over ten years, especially whenever there was a scheduling snag with a system delivery.
The sales rep was complaining about me personally, on behalf of the executive who was in charge of their relatively new networking group. There had been an introductory meeting between their technicians and some of our people, including myself. Our understanding was they would be responsible for network design, and their field engineers would handle servicing.
The letter referred to the irate customer who had called me about his troublesome terminal servers. I was accused of bad-mouthing the other company in that call. The letter’s wording was inflammatory, almost as if I’d committed slander against the executive in charge, whose name I didn’t even recognize. I was called a poor representative for my employer, I wasn’t a good partner, and I should be fired for my uncooperative behavior.
The VP wasn’t mad, he just wanted to know what happened with the customer. I gave him a brief rundown on the problem, how I became aware of it, what I had done to find it, and Field Change Order #42. I had no further direct contact with the customer myself, and I had no idea what he did after the call to cause so much trouble within the hardware vendor’s organization. I certainly hadn’t spoken against them, and I didn’t even know if the networking group had been involved. The customer had demanded to know why the FE didn’t know about the change order, and all I could say was that I had no idea.
The VP thanked me and said that I should make more of an effort to be sensitive to the partnership between the companies. I went back to my desk, and needless to say I was outraged. The way the letter was written, I doubted the sales rep had even written it. But even if he had been a reluctant front man for the accusations against me, I considered it an unforgivable act.
I never heard anything about follow-up between our VP and the manufacturer. I could only hope that he saw through the letter the way I did, as me being thrown under the bus by someone to cover their own butt. If the manufacturer hadn’t figured out how to coordinate field engineering with the networking group, that wasn’t my problem.
When further contact with the sales rep became unavoidable, he offered a half-hearted non-apology. “About what happened… that was a bad idea.” A bad idea for him to sign the letter, or a bad idea for me to have handled situation with the customer the way I did?