OSI/TS Configuration and Management Manual

Performing Monitoring and Troubleshooting Guide
OSI/TS Configuration and Management Manual—424831-001
4-10
Common Causes of Problems
example, NSP processes support Layer 2 and the X.25 I/O operations in Layer 3; TSP
processes support Layer 4 and the LAN I/O operations in Layer 3. One of the
advantages of OSI is that problems can be diagnosed and tracked to a distinct layer; you
don't always need to concentrate on the entire communications environment.
Of course, no layer is completely independent. Layer 4, for example, can interact with
application requests, and sends service request primitives to Layer 3, below.
Nevertheless, each layer has its own distinct function.
Concentrate on the Layer Exhibiting the Problem
When you are troubleshooting a problem, the best approach is to begin with the
assumption that the lower layers (and thus the subordinate Compaq processes) are
operating normally. This means you can concentrate first on the interactions of the
immediate layer–the layer at which the problem becomes apparent.
If your OSI/TS subsystem is part of a multilayer configuration of networking products,
you should also try to analyze problems in the higher layers first. This helps to produce
a clear picture of what was happening outside of the OSI/TS subsystem.
Analyze Known Errors
The first step is to analyze the known errors. If the error reported is a connection error
(for example, error 140), then you would check the Transport Layer to see if it returned
an error. If the Transport Layer also reports an error, then you would check for errors in
the subordinate Network Layer, and so on, until you eventually arrive at the original
source of the error.
Check Your Configuration
As with many data communications problems, you will find that most of your problems
can be tracked to your initial OSI/TS configuration, regardless of what layer you are
starting from. You can overcome almost all OSI errors either by changing your
configuration or by changing the sequence of the procedure calls in your application.
Analyze the User Application
The Inspect utility allows you to look at your application code. Possible problems that
can be detected using Inspect are program bugs, incorrect names, out-of-sequence
procedure calls, various error conditions, and interoperability problems.
To use Inspect, run the application under Inspect and establish breakpoints at which to
test the data. Run the application program and view the data that the Inspect utility
displays. Analyzing the data displayed by Inspect may point out the location of a
problem in the code. For details on using Inspect, refer to the Inspect Manual.
Common Causes of Problems
There are three general areas in which problems are likely to occur:
•
Outgoing transport connection request failures