Specifications

Debugging a Device Driver
11.4 Troubleshooting Network Failures
Value Status
2, 4, 6 Internal network error, submit an SPR with the code.
8,10,14,16,18,20,26,28,34,38 Network protocol error, submit an SPR with the code.
22,24 Too many errors on the network device most likely due to congestion.
Reduce the network traffic or switch to another network backbone.
30 Target system scratch memory not available. Check DBGTK_SCRATCH. If
increasing this value does not help, submit an SPR.
32 Ran out of target system scratch memory. Increase value of DBGTK_
SCRATCH.
All others There should not be any other network error codes printed. If one occurs
that does not match the above, submit an SPR.
11.4.1 Access to Symbols in OpenVMS Executive Images
Accessing OpenVMS executive images’ symbols is not always straightforward
with the system-code debugger. Only a subset of the symbols may be accessible
at one time and in some cases, the symbol value the debugger currently has may
be stale. To understand these problems and their solutions, you must understand
how the debugger maintains its symbol tables and what symbols exist in the
OpenVMS executive images. The following sections briefly summarize these
topics.
11.4.1.1 Overview of How the OpenVMS Debugger Maintains Symbols
The debugger can access symbols from any image in the OpenVMS loaded system
image list by either reading in the .DSF or .EXE file for that particular image.
The .EXE file only contains information about symbols that are part of the
symbol vector for that image. The current image symbols for any set module are
defined. (You can tell if you have the .DSF or .EXE by doing a SHOW MODULE.
If there are no modules you have the .EXE.) This includes any symbols in the
SYS$BASE_IMAGE.EXE symbol vector for which the code or data resides in
the current image. However, a user cannot access a symbol that is part of the
SYS$BASE_IMAGE.EXE symbol vector that resides in another image.
In general, at any one point in time, the debugger can only access the symbols
from one image. (A later section describes how to get around this limitation). It
does this to reduce the time it takes to search for a symbol in a table. To load the
symbols for a particular image, use the SET IMAGE command. When you set an
image, the debugger loads all the symbols from the new image and makes that
image the current image. The symbols from the previous image are in memory
but the debugger will not look through it to translate symbols. To remove symbols
from memory for an image, use the CANCEL IMAGE command (which does not
work on the main image, SYS$BASE_IMAGE).
There is a set of modules for each image the debugger accesses. The symbol
tables in the image that are part of these modules are not loaded with the SET
IMAGE command. Instead they can be loaded with the SET MODULE module-
name or SET MODULE/ALL commands. As they are loaded, a new symbol table
is created in memory under the symbol table for the image. The following figure
shows what this looks like:
11–12