Tips & Techniques - LAN Systems - April 1996
Note: This a digest from The IBM LAN Server Sourcebook: "How to Connect Your Business at Warp Speed", by Pat Scherer and Charlie Brown. (John Wiley and Sons, 1996) ISBN 0-471-13170-9, IBM Puborder #: SR28-5960-00
Tip: Observation is one of the most important tools you have for detecting and isolating LAN problems. An equally important factor in observation is familiarity with how the network normally runs (or should run).
Technique: A truly serious problem rarely happens all at once but is often a sequence of events that could be more easily corrected if detected early. Examples of these sorts of problems are running out of resources such as buffers, CPU capacity, memory, disk space, data transmission bandwidth, and some hard disk failures. Your best tool for detecting these sorts of problems before they turn into emergencies is to regularly monitor your network and compare the data for changes over time.
Tip: Error and transaction logs are useful sources for help in problem determination.
Technique: Three logs which are useful for debugging network errors are the LANTRAN.LOG located in the IBMCOM subdirectory, LAN Server Error Log, and the OS/2 System Log.
The LAN Server Error Log can be viewed by selecting the Error Log icon within the Administrative GUI. The OS/2 System Log can be displayed by entering SYSLOG at an OS/2 command prompt. LAN Server also keeps a statistics log which is accessed via the NET STATISTICS, or NET STATS command.
Tip: LAN Server provides several productivity aids that can help you identify problems:
- DIRSTAT displays network adapter status.
- FINDNAME locates duplicate NetBIOS names.
- LSS monitors network errors, messages and alerts and provides problem determination support.
- NCBSTAT displays NetBIOS statistics.
- NETSESS2 displays session statistics.
- RDRDEBUG dumps LAN Server internal data structures.
- SMBTOOL captures and views System Message Blocks.
- SNAPDF formats and views SNAPDUMP data.
- SNAPDUMP data collection tool.
Tip: Isolate your problem.
Technique: First try looking for the source of the problem by checking error logs and looking for anomalies in the configuration, statistics, traces, and dumps.
If the problem leaves no trail of evidence, methodically change one factor at a time to either recreate or eliminate the problem. All data collected during the indirect approach is relevant and should be noted. Really tricky problems may be intermittent: changing one factor may increase or decrease the frequency of the problem reoccurring. Other difficult problems to isolate are those triggered by a combination of parameters or events; these require research into how the parameters interrelate. Be sure to back up and record the original configuration before attempting any changes.