Workshop

Application Antics
Previous Table of Contents Next
Let’s travel back to Hour 18, “Lots of Different People in Your Neighborhood: In-depth Application
Troubleshooting,” to the problem in the “I Can’t Spool, Take Two” section. Remember that we had a
UNIX host that would not spool more than one print job to a given network print server at one time, even
if that print server had multiple printers attached to it. In other words, the host assumed that each print
server only had one printer—a seriously wrong assumption! In this scenario, even though I had proved to
myself that the host was at fault by using black box troubleshooting, I wanted evidence to submit to the
vendor to prove that its stuff worked differently (wrongly) from other vendors’ implementations of
UNIX printing in order to try to force the vendor to fix it.
It was fairly easy to take a trace of this by specifying a capture filter of the print server’s MAC address or
TCP/IP address. Why not the UNIX host? Because the UNIX host had hundreds and hundreds of users,
all accessing it via TCP/IP—had I specified the UNIX host, I would have had a little more data than I
could handle.
I set up two test queues on the suspect host—queue1 and queue2—one for each printer on the print
server. As a “control experiment,” I set up the same two queues on another host. I started the analyzer
capture, went back to my desk, and quickly printed two jobs to the two test queues. I went back to the
analyzer, stopped the capture, and saved it to disk, giving it the filename problem.
Then I did the exact same procedure, but used another host to print to the queues. I called this trace file
good, because this capture illustrated what happens with a UNIX host that’s not brain dead. (Although
the vendor didn’t immediately act, our salesperson saw that we acted on this objective data and bought
something else, which had good long-term effects on our leverage with this vendor—so it was worth
doing. In fact, when we started having more problems with the machine and implementation of UNIX,
we were given a new machine in reparation.)
Here are the important points to remember when submitting analyzer traces to a vendor:
• Traces should be small. Filter as much as you can.
• Traces should be discrete. As shown earlier, you should take several traces showing a “good”
event versus a “bad” event.
• Traces should be backed up with an objective and succinct description of the problem,
describing what troubleshooting measures were taken.
Identifying a Station