While at CONVEX's Technical Assistance Center, I had a few "favorite" calls. These are the amusing ones you just have to laugh about:
Either select a call from the list above, or scroll through this page. Some of the calls from when I worked at the University of Michigan are available too.
One of my favorite calls of all time was when Anna (not her real name) called from a major oil company. According to my dispatcher, she needed to set up her CONVEX machine to be a primary DNS name server. So I had my instructions out in order to walk her through the steps to do so.
She asked, "What book do I look in for the instructions?"
Given that CONVEX could measure its documentation in shelf-feet (documentation was in 3-ring binders at the time, though even when we switched to perfect-bound 7-by-5-inch books, we had shelf-feet of documentation), it wasn't a dumb question by any means. I told her the binder, the book within the binder (there were 4 books in that specific binder), and the chapter within the book. I also gave her the call number and asked her to please call me if she had any questions.
Years later, I ran into Anna at a conference. I told her that she was one of my favorite calls. She explained that she learned by reading-and-doing, and if I had simply walked her through the process she'd've never remembered it for the next time. Classy lady, and I'm glad she was one of my customers.
My dispatcher puts through a call with the problem description "Needs to shut down in a hurry." So I take the call, and I can hear sirens sounding in the background.
"I'm a manager. Both my primary and backup sysadmins are out right now. I don't know the root password. We've had a power failure and the UPS will run out of battery power in about 5 minutes. How do I shut down the CONVEX gracefully?"
Unfortunately in this case, the short answer is "You don't." You also don't tell the customer that in so many words. Luckily, CONVEX machines had a dual-level system: the Central Processing Unit (CPU) handled the jobs and the OS and scheduling and all the rest of the things users expect of their computers, while the Service Processing Unit (SPU) ran a less-complex, older, trimmed-down version of UNIX that basically made sure that the hardware was functioning and the environment was okay (fans moving, air cool enough, boards processing data, etc.). We forcibly crashed the CPU by telling the SPU to do so ("osclean"), then gracefully shut down the SPU. They made it in time.
Recovery was not a problem; crashing the CPU the way we did was the equivalent of shutting power off to a UNIX-based workstation, without the risk of hardware damage. They had to spend some extra time fsck-ing the disks on the CPU when it came back up, but that was it. Happy customer.
I got an after-hours page once from a customer at one of the NASA sites. In speaking with the operator from the site who called in the problem, I realized she was talking to someone on her end as well. I asked her if she was talking to Natalie (not her real name), who I knew pretty well from previous calls. She said it was. So I said, "Go away! Solve your own problems! I don't care about this tonight!!"
As I expected, she repeated it word for word to Natalie, who laughed. She came on the phone and we chatted about the problem, the likely cause, and what we could do to fix it that evening. When my pager went off a few minutes later (when we were rebooting the machine to see if we could get more information on the subsystem that was hanging), I hung up on Natalie and resolved the other customer issue — while staying connected to Natalie's machine and fixing the subsystem problem.
(Note: As a general rule, you shouldn't tell your customers to go away. They might take offense — or truly leave your comapny forever. This is usually a Bad Thing.)