Enter your search terms Submit search form
	Web pdp-10.trailing-edge.com

             How to Deal with Network Problems

     If you have a problem with your network there  are  two
actions  that  you can take.  You can do everything possible
to recover from the error to get the network back on the air
as  fast as possible, or you can collect all the information
necessary for problem analysis.  (A combination of  the  two
is also possible.)
                     DISASTER RECOVERY

     A communications network contains many components which
can  fail.   Quick  recovery  may be as easy as restarting a
program, or turning off a line.  The key is isolation of the
problem.   The  following  paragraphs  outline  a  number of
situations and what can be done in each  to  circumvent  the
problem and recover quickly.

     APPLICATION FAILS.  If the  application  level  program
fails, try it again.  A number of network errors are related
to limited resource problems.  When more of the resource  is
free the problem goes away.

     NETCON FAILS.  When commands to the NCP subset  of  OPR
fail  to  give  a  response, NETCON may be hung in some way.
Remember that some commands take a long time, or  may  never
be executed (i.e.  an executor which doesn't exist).  If the
SHOW EXECUTOR command doesn't  respond  NETCON  is  probably
hung.   Application  programs  will continue to work without
NETCON,  so  that  you  can  easily   restart   it   without
interfereing    with   netwrok   operations.    Follow   the
instructions in the manual for restarting NETCON.

     FRONT-END CRASH.  NETCON will  automatically  dump  and
reload the front end.

     MODEM and LINE PROBLEMS.   If  your  error  rate  (SHOW
COUNTS  COMMAND)  for  a  line  is  high,  or the line fails
completely.   you  may  have  a  backup   modem,   or   dial
capability.   Just  set  the  line  off,  establish  the new
connection and set the line on again.

How to Deal with Network Problems                     Page 2


                   COLLECTING INFORMATION

     If you choose to work on your  network  problem  before
calling on the hotline or writting an SPR remember that your
first goal is to collect  sufficient  information,  then  to
isolate  the problem, then to solve or circumvent it.  After
taking   the   following   steps   to   gather   preliminary
information,  consider using any of the tools on the SWSKIT,
a datascope, and other specialists in your office if  its  a
mixed network.

     If you choose to call the hotline or prepare an SPR  to
solve a problem with a DECnet network, you should gather the
following materials at a minimum.  More information, or  the
use of a datascope could be required.

     1)  A  complete  description   of   the   configuration
including  all  the  nodes,  their system types, names, node
numbers, comm interfaces,  line  speeds,  modem  types,  and
anything else you can think of.

     2) A description of the problem.  Include the  time  of
day  and  anything that happened in the systems which seemed
out of the ordinary.  If you have just upgraded  or  changed
your  configuration  describe the changes you made.  Include
with this information console sheets  and  listings  of  any
possible offending programs.

     3)    The    syserr    file,    or    syserr    listing
(DECsystem-2040/50/60  only)  and  the  console sheets.  The
DECsystem-2020 does not record syserr entries for  DECnet-20
V2.0.   For  other  systems  include the output from the log
device.

     4) All documents  associated  with  the  generation  or
definition  of the network.  For the KL based DECsystem-20's
this    includes    the    NETGEN    saved    image    file,
NETGEN-CONFIG.IMAGE,   the   log  from  the  network  build,
BUILD-ALL.LOG, all STB and MAP files,  and  CETAB.MAC  (i.e.
the  entire contents of the directory that you are requested
to create in the installation instructions.) For all TOPS-20
systems  this includes the 4-CONFIG.CMD file and any command
files given to the NCP subset of  OPR  at  system  start  up
time.   For  non TOPS20 systems, this includes all documents
generated during the NETGEN process.

     5) And finally, any dumps that are available.  Remember
that  a  KL  or  KS  dump  requires  the MONITR.EXE file for
symbols definition and the front end dump requires  all  STB
and MAP files for symbol definition.

How to Deal with Network Problems                     Page 3


     If your network is a heterogeneous network, the problem
may  not  be  easily solved by the information from one node
alone.  If you prepare an SPR or call the hotline, have  the
information  for  all the nodes ready.  The network software
support staffs work together to solve  network  problems  in
mixed  networks.   Please  make  only one call to one of the
hotlines.  Make it clear that you have a  network  of  mixed
node  types  and  we  will  make  the  rest of the contacts.
Thanks, and enjoy DECnet.