NO MORE UPDATES TO THIS PAGE PLEASE. SUBMIT ALL FUTURE COMMENTS TO

This chapter should include Trey's 500-mile email story!

-- BenjyFeen - 16 Sep 2006

[ Tom's reply: Status: DONE. ]

4.1.1 pg 80

Talking of customers, it's common for customers to use jargon but in an incorrect way. They may talk of frobnitzing the whangamy because they believe that's what the SA wants to hear. They're trying to be helpful. It's very valid for the SA to respond along the lines of "Let's back up a little; what exactly is it you're trying to do? Just describe it without being technical." When a junior SA misuses jargon to me I just tell them "You're using words but they don't mean anything"; I'd never say that to a customer unless we were friends!

[ Status: DONE ]

4.1.3 pg 83

Hmm, my initial thoughts here are potentially covered in 4.2.3; Know the environment. However, the anecdote is a good one, I think.

At my first job we had an analog leased line between the London and Piraeus (Greece) offices. It was only 9600 bits per second. The modems at each end would compress the data, providing a hopeful 19,200 bps. These were plugged into equipment that took the synchronous data and split it into 2 voice lines (each allocated 4800bps) and one async serial line (9600bps). The async serial line was then plugged into a muxer which provided 4 serial connections for use. So from the outside we had 4 serial lines and 2 voices all going through this poorly overloaded leased line. Given the line itself went via Yugoslavia and there was a war on, reliability wasn't the best in the world. The serial lines were setup so that 2 allowed London to initiate connections to Greece, and two allowing Greece to London. We used them mostly for UUCP traffic (email!) and interactive SA work. One day the SA from the Greek office phoned me up; she was unable to to connect to the London terminal server. Was it down? In surprise I asked her why she thought it was down. It turns out that because her interactive session wasn't working she didn't check any further. I spent some time leading her through the configuration and getting her to think "what would I see if the problem was here; how could I test this?" Obviously it wasn't the line itself (she was talking to me on it), it wasn't the London terminal server (the other connection was working) and those showed it wasn't likely to be the leased line hardware or muxes. Enlightenment struck and she exclaimed "Oh, this is the same problem we saw 2 months ago!" The Greek terminal server had a firmware bug that caused it to occaisionally hang a port. The temporary solution was to move the serial cable to another port until after hours, when the terminal server could be rebooted. Knowledge of the environment and 5 minutes worth of thought and logical analysis of the configuration can help narrow down the scope of the problem to a much smaller number of cases, which can then be tested without any disruption of other services.

[ Tom's reply: Great story. I can't find a good place to fit it. ]

4.1.3 pg 84

The NFS issue you describe debugging could also have been a DNS server failure, either misconfigured (forward/reverse lookups don't match) or a temporary outage causing a bad response to be cached. Kill nscd and retry

[ Tom's reply: I can't find this in the text. ]

-- StephenHarris - 11 Aug 2006