Bill: This chain continued until several users were locked up, since the server had not fulfilled the first request.

Scott: This "cascading table lockup" problem appeared to be a glitch inside the SQL server rather than any networking component.

Bill: This was reinforced by the fact that the workstations received only TCP acknowledgments and waited on the server for the data indefinitely.

Scott: Although the application programmers could have programmed a time-out and notified the current user that the server was not responding, the root of the problem was in the SQL server.

Bill: Luckily, we didn't have to completely update the server to the latest release, relying instead on patches provided by the vendor.

Scott: After the vendor-recommended patches were installed, we carefully monitored the workstations andı

Bill: ıwe no longer encountered a table lockup problem.

Scott: Ah, so far it was not a network problem. But, what about the second situation?

Bill: Because the workstation received the data and then locked up, one might suspect an application or operating system problem.

Scott: One way to check whether we had a complete Windows95 meltdown was to try to operate other applications at the "hung" workstation.

Bill: Since the task manager would not respond to Ctrl-Alt-Delete, it didn't seem likely we'd get very far.

Scott: We could still ping the workstation, however, indicating that the IP stack and workstation weren't completely dead.

Bill: Taking it one step further, we decided to reboot the workstation and temporarily enabled the share function on that workstation's local hard drive.

Scott: Within an hour or so of running the SQL application, the workstation locked up again.

Bill: Interestingly, we could still get to the hung workstation from a different workstation and transfer files back and forth, despite the fact that the hourglass was omnipresent on the hung workstation.

Scott: Although we couldn't yet rule out the operating system altogether, it was looking more and more like an application problem.

Bill: Presented with this new information, the appli cation developers started digging into their code and making a few changesı

Scott: ıand before we knew it, the workstations became more stable.

Bill: What about the correlation between lockups and network traffic?

Scott: One thing that always comes to mind is the possibility of broadcast storms or even brief periods of heavy broadcasts wreaking havoc on network workstations.

Bill: Because we've seen this happen on other networks, we ran a quick analysis of the broadcast traffic.

Scott: The occasional bursts of broadcast traffic for this customer were well under 100 broadcasts per second.

Bill: Testing a workstation on an isolated segment revealed that it could handle well over 500 broadcasts per second sustained, without a hi tch.

Scott: This was good news. Older Windows 3.1 and Windows for Workgroups workstations would often lock up with broadcast bursts because the drivers couldn't handle the load, and they often ended up overwriting part of memory containing other applications or part of the operating system.

Bill: This caused workstations to hang, or, in some cases, even reboot. Thankfully, we didn't appear to have this situation with the current Windows95 workstations.

Scott: While we ruled out a broadcast traffic-related problem for the moment, it's always something to consider.

Bill: As it turned out, the workstation lockups were more common during periods of heavier traffic simply because that's also when more people were using the application, thereby increasing the probability that someone would report a lockup.

Scott: So, is th e network always to blame? After a little forensic analysis, you make the call. n

Bill and Scott can be reached at otw@pmg.com. Portions of trace files from selected columns are available via Pine Mountain Group's Home Page (www.pmg.com).