OSI/AS Configuration and Management Manual

Troubleshooting Guide
OSI/AS Configuration and Management Manual—424119-001
8-8
An Approach to Troubleshooting
An Approach to Troubleshooting
The OSI/AS subsystem includes various processes—the processes NSP, TSP, TAPS, and
the OSI manager process—as well as the API. The interaction of these processes with
each other and with the peer protocols at each layer can lead to difficulties when your
subsystem is configured improperly, or when an application loses its synchronization
with the connection. This subsection describes a strategy for diagnosing problems in
your OSI/AS subsystem. This strategy generally involves six basic steps:
1. Reset the statistics counters and rerun the application (this simplifies the information
on statistics screens).
2. Analyze the errors returned to the application.
3. Review the statistics and status using SCF.
4. Collect trace information using SCF.
5. Analyze the trace using PTrace.
6. Correct the problem.
These steps are discussed more fully later in this subsection.
A Top-Down Troubleshooting Method
To interpret symptoms correctly and identify where problems lie, you should have a
basic understanding of how the different components of OSI/AS work together to
support a connection. The main components of an OSI/AS end system—the processes—
are designed to simulate the distinct layers of the OSI Reference Model. For example,
NSP processes support Layer 2 and Layer 3; TSP processes support Layer 3 and
Layer 4; and TAPS processes support Layer 5, Layer 6, and ACSE in Layer 7. 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 5, for example, interacts with
application requests from higher layers, and sends service request primitives to Layer 4,
below. Nevertheless, each layer has its own distinct function.
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 should concentrate first on the interactions of the
immediate layer (the layer at which the problem becomes apparent).
The first step is to analyze the errors returned by the API. The service ID returned tells
you right away whether the error was detected by the API or the TAPS process. If the
service ID points to Layer 5, Layer 6, or ACSE in Layer 7, check the information (using
the APS_STATUS_ procedure) in the error to determine the layer in which the problem
occurred. If one or two SPDUs have been exchanged in Layer 5, chances are the lower
layers are intact. If none were exchanged, then you need to work your way down to the
next-lower layer, then to the TSP process, and so on.