Trailing-Edge - PDP-10 Archives - BB-H348C-RM_1982 - swskit-v21/documentation/netcon.doc
There are no other files named netcon.doc in the archive.


     NETCON is the  TOPS-20  module  which  controls  DECnet
operation;   it  also  makes  DECnet-related SYSERR entries.
NETCON performs the functions of both  the  network  control
utility  (NCU) and the network control program (NCP).  Since
NETCON's job is to service requests, it spends most  of  its
time   waiting   in  its  background  loop  for  a  software

     The NETCON code is written in three basic sections, the
NCP,  the  NCU  (or  the NICE process), and the logger.  The
process acting as the NCP executes the first section of  the
code.   This  process  creates  inferior processes to act as
NCUs;  these NICE processes execute the  second  section  of
the  code.  The NCP process also creates an inferior process
to perform the  SYSERR  logging  operations;   this  process
executes  the third section of the code.  Thus, the NCP, the
NCUs, and the logger have  identical  address  spaces,  they
simply execute different sections of the code.

	The source of NETCON is in three files, NCP.MAC,
NCU.MAC and NETPAR.MAC. Ncp code is in NCP, Ncu code and the
logger are in NCU, and most definitions and macros are in


     When NETCON  is  started  it  first  goes  through  the
following series of initialization routines:

     1.  PACINI - set the page access code of all pages containing
	code to read and execute. This catches any process which
	attempts to overwrite the code.
	Note that this will prevent you from inserting breakpoints
	with DDT. To use DDT with NETCON change the MOVEI 1,5 at

     2.  FREINI - zeroes  variable  storage,  unmaps  pages,
         initializes pointers

     3.  PSIINI - sets up PSI system

     4.  JFNINI - opens 4 JFNs on device SRV:NCU

     5.  PIDINI - gets a PID to talk to ORION

     6.  HELLO - says hello to ORION

     7.  NAMINI - sets the default executor node

     8.  SYRNCU - make "NETCON started" entry in SYSERR

     9.  LOGINI - CFORKs the logger

    10.  TOPINI - initialize topology monitoring

    11.  ATOINI - initialize auto dump/load monitoring

     When the initialization is complete the background loop
BGLOOP  is  entered.  The background loop performs two basic
tasks:  1) process messages that come from the operator, and
2)  send  messages to the NICE processes.  For example, some
commands  (e.g.,  SET)  simply  modify  NETCON's  data  base
providing  information necessary for future events.  Second,
other commands (e.g., LOAD) request action;  these  commands
usually  require  sending  messages either a) over a network
                                                      Page 2

logical link to an NCU, or b) back to  the  operator.   When
there  are no operator or NICE messages to be processed, the
NCP goes to sleep.

     There are five types of interrupts which  wake  up  the
NCP:   1)  a  message  arrives  from the operator, 2) NCU
logical link activity, 3) a NICE process  has  terminated,
4) topology change or topology polling timout, and 5) fatal
error interrupts. The
interrupt routines wake up the background  loop  if  it  was

     All operator  commands  are  parsed  by  OPR  and  sent
through   ORION  to  NETCON  via  IPCF  messages;   NETCON's
interrupt-level routine PIDINT places these messages  in  an
internal  IPCF queue pointed to by location QUEUE.  An entry
on the queue has the following format:

  !  Address of IPCF Message  ! Ptr. to Next Queue Entry  !
  !  Type of Entry (.QTXXX)   !      Flags (QF%XXX)       !

                .QTMES=0     Data Message
                .QTFKT=1     Fork Termination
                .QTJFD=2     JFN or Disconnect
		.QTTOP=3     Topology change

                QF%NOA=1     Don't ACK yet to ORION
                QF%TXT=2     There is text for OPR

It is the background loop which notices that  the  queue  is
non-empty and shifts control to the operator request handler
DOREQ.  (The interrupt system is turned off while processing
the  queue.)  Once  the  command has been validated, control
shifts to the appropriate service routine.

Command   Routine            Action

DISABLE  DISREQ   Construct a NICE message to disable event
		    logging for a node or line and place it
		    on the NICE queue.

ENABLE	   ENAREQ   Construct a NICE message to enable event
		    logging for a node or line and place it
		    on the NICE queue.

LOOP	   LOPREQ   Construct a Loop-line NICE message and put
		    it on the NICE queue.

SET        SETREQ   Store a parameter in the data base

LOAD       LOAREQ   Construct a Request-Down-Line-Load  NICE
                    message and put it on the NICE queue

DUMP       DMPREQ   Construct  a  Request-Up-Line-Dump  NICE
                    message and put it on the NICE queue

SHOW       SHOREQ   AssembAle the requested information into
                    an  IPCF  message  and  send  it to OPR;
                    some SHOW commands require  constructing
                                                      Page 3

                    a  NICE  message  and  putting it on the
                    NICE queue

INITIATE   INIREQ   Modify  the  data  base  so  that   line
                    counters are logged

TERMINATE  TRMREQ   Modify  the  data  base  so  that   line
                    counters are not logged

     As indicated previously, some commands require messages
to  be sent in the NICE protocol over a network logical link
to an NCU.  The routine STONIC places these messages  in  an
internal  NICE queue pointed to by location NICQUE.  As with
the IPCF queue, the background loop periodically checks (via
the  routine  CHKNIC)  the  NICE  queue and attempts to send
messages that it finds.  (All NICE messages  adhere  to  the
Network  Information  and  Exchange  Protocol Specification)
Entries on the NICE queue have  the  following format:

  !   Ptr. to ORION Message   ! Ptr. to Next Queue Entry  !
  !        Request No.        ! No. of Bytes in NICE Msg  !
  !  request entry time       !  address of NICE mess text!
  !  NICE function code       ! sub function (option) code!
  !    flags                  ! address of executor string!

     An NCU is responsible for responding  to  NICE  message
requests.   Before  describing  what  an  NCU  does, certain
features of DECnet architecture must be  understood.   There
are potentially four nodes involved in a down-line load:  1)
the command node, 2) the host node, 3) the server node,  and
4)  the  target  node.   The  request is made at the command
node;  the host has the file to be loaded;   the  server  is
the  node  directly connected to the target.  This structure
requires an NCP to inform the host's NICE process  which  in
turn  must  establish  a logical link with the server's NICE
process.  Once the server NICE gets  the  appropriate  file,
the  server  NICE  sends  it  to the target.  Very often the
command, host, and server nodes are the same.

     When any process  tries  to  make  a  connection  to  a
TOPS-20   NCU,  a  software  interrupt  is  generated;   the
interrupt-level routine JFNINT starts the NCU in an inferior
process  and  passes the JFN of the connector to the NCU via
the PRARG JSYS.  When an NCU is sent a request,  a  software
interrupt  is  generated  and  the  interrupt-level  routine
JFDINT sends the request to the NCU;  when the  request  has
been   processed,   the  superior  process  is  notified  of
inferior's  termination  via  a  software  interrupt;    the
routine FRKTER processes the interrupt.  (If the NCU process
terminates due to  an  error,  a  message  is  sent  to  the
                                                      Page 4


     When an inferior NCU process is started it  first  gets
the  JFN of the connecting logical link.  After clearing the
per-NCU message area, it then executes a SINR  JSYS  to  get
the incoming NICE message from the logical link.  Finally it
extracts  the  NICE  function  code  from  the  message  and
dispatches  to  the apropriate routine.  When the NCU has no
more requests it does a CLOSF on the logical link  and  then
halts.   It  is  important  to  note that responding to some
requests requires establishing logical links to  other  NICE
processes,  e.g.,  a  server,  if  you are processing a load

The Logger

     The inferior process  acting  as  the  logger  contains
routines  which  make  SYSERR entries for node startup, node
dump, and NETCON startup.  This  process  also  periodically
checks  through  the  node  information  blocks to see which
lines currently require logging of line counters;  this data
is also entered into the SYSERR file.

Error Messages

     The following is a list of NETCON's error messages  and
the routines which can produce them:

 Code   Error No.     Error Message

JFNINI    1     Could not open any JFNs for the NCU task

PIDINI    2     Could not create a PID for  receiving  ORION

HELLO     3     Could not send "HELLO" message to ORION

PIDINI    4     Could not set up PID interrupt channel

ASGPAG    5     No more free pages available

RELPGA    6     Attempt to return an illegal page address

RELPGA    7     Attempt to return a page that is already  on
                the free list

GETFRE    8     No more free space available

RELFRE    9     Attempt to return a free block  outside  the
                free pool area

RELFRE   10     Attempt to return space already marked as in
                the free pool
                                                      Page 5

         11     ORION is not running

OPRMES   12     Failed to successfully send a message to OPR

DOREQ    13     Unimplemented NETCON command

DOREQ    14     Unknown internal NETCON message type

SETFIL   15     Exhausted table space for the known nodes

GETRQI   16     All server JFNs in use

DOFRT    17     NCU process halted prematurely

DOREQ    18     Unknown message type received from ORION

SETLCL   19     JSYS error

NAMINI   20     Could not get name of local node

CHKLOG   21     Could   not   log    line    counters    for
(NCU)                communications line

NETINI   22     Could not initiate Logging Process

SETLCL   23     Invalid line-id

LOALIN   24     Could not open file

LDKMC1   25     Bad data in load file

NETINI	 26	Could not initiate automatic load/dump

NETINI	 27	Could not obtain network topology

TOPINT	 28	Could not set up topology change server links

DOLOG	 29	SYERR JSYS failed creating SYSERR entry

GETFRE	 30	Free pool chain sequencing error, blocks not sorted correctly

	Note that many many places in the code use the macro FATAL.ERROR
without a NETCON error code. This produces the message "Unknown NETCON error".
These problems may be hard to trace down. We suggest inserting code which
reports the PC when this occurs and rebuilding NETCON.
                                                      Page 6

        Name:  ADJTAB

        Description:  This table contains information  about
                physical  lines;  there is an entry for each
                line for which NETCON has  been  declared  a

        ! LTTYP                     ! LTCTL                     !
        ! Line Device Type (.DTXXX) !  Line Controller Number   !
        ! LTUNI                     ! LTSTN                     !
        !     Line Unit Number      !      Station Address      !
        ! LTFLG                     ! LTNIB                     !
        !           Flags           ! NIB addr. of Target Node  !
        ! LTHST                     !                           !
        !Addr. of NIB of Line's Host!                           !


         .DTP11 = 0     DP11
         .DTU11 = 2     DU11
         .DTL1E = 4     DL11E
         .DTQ11 = 6     DQ11
         .DTA11 = 8     DA11A
         .DTDUP = 10    DUP11
         .DTDMC = 12    DMC11
         .DTDLV = 14    DLV11
         .DTL1A = 16    DL11A
         .DTKL8 = 18    KL8J
         .DTDTE = 20    DTE20
         .DTDV1 = 22    DV11
         .DTKDP = 28    KMC11/DUP11
         .DTKDZ = 30    KMC11/DZ11      

         LTUSE=B0       This entry is in use
         LTLOG=B1       Log counters for this line
                                                      Page 7

        Name:  LINTAB

        Description:  This   table   contains    information
                describing the physical lines eminating from
                the node on which NETCON is running.   There
                is  one  entry  (LTBSIZ words long) for each
                physical line.  The illustration below is of
                one such entry.

        !              !LNLDN       !                           !
        !              !Load Number !                           !
        ! LNPGM                     ! LNCNT                     !
        !   Program Type (.PTXXX)   !Bytes Left to Dump in Block! *
  LNPTR !      Ptr. to Next Byte to be Returned on a Dump       !
        ! LNDTE                     ! LNCPU                     !
        !   DTE20 # for This Line   !CPU Type of Target (.CPXXX)! *
  LNADR !          Base Address for Next Load or Dump           !
  LNMSG !             Pointer to MOP Message Block              !
  LNDCT !          Total Number of Bytes to be Dumped           !


         .PTSLD = 0       Secondary Loader
         .PTTLD = 1       Tertiary Loader
         .PTOPS = 2       Operating System (Primary Load File)
         .PTSDM = 3       Secondary Dump File
         .PTTDM = 4       Tertiary Dump File


         .CP8 = 0         PDP-8
         .CP11 = 1        PDP-11
         .CP20 = 2        DECSYSTEM-10/20
                                                      Page 8

        Name:  NIBTAB

        Description:  This table contains a Node Information
                Block  (NIB)  for each node known to NETCON.
                NIBs are connected by pointers based on  the
                newtwork  configuration.  For a target node,
                the NIB has the name  of  the  server  node;
                for  a  server  node,  the  NIB  contains  a
                pointer to the Line Adjacency Table (ADJTAB)
                which  contains  the  address of the NIB for
                the target node on the line.   Each  NIB  is
                NIBSIZ  words in length.  Given a node name,
                the associated NIB  is  found  via  a  table
                lookup in NODTAB.

        ! NDFLG                     ! NDNUM                     !
        !           Flags           !        Node Number        ! *
  NDBP1 !          Boot Password Needed to Trigger the          !
        !------                                           ------!
  NDBP2 !                   ROM at This Node                    !
  NDLOD !            Ptr. to Primary Load File Spec             !
  NDDMP !            Ptr. to Primary Dump File Spec             !
        ! NDINT                     ! NDTMO                     !
        !      Status Interval      !Status Reply Time-Out Value!
  NDLIN !            Address of Line Adjecency Table            !
  NDNAM !                Ptr. to ASCIZ Node Name                !
        !NDTPS!NDTPP!               ! NDPRO                     !
        !     !     !               ! Protocol Version (.VNXXX) ! *
  NDSRV ! Ptr. to ASCIZ Default Server Node Name for This Node  !
  NDSL1 !                        Server                         !
        !------                                           ------!
  NDSL2 !                        Lineid                         !
  NDPNA !         Node Name (Parameter Passed to Node)          !
  NDPNU !        Node Number (Parameter Passed to Node)         !
  NDPHT !    Host for Task Loads (Parameter Passed to Node)     !
        ! NDLDV                     ! NDCPU                     !
        ! Boot Device to Load Node  !   CPU Type of This Node   ! *
                                                      Page 9

  NDCNT !          Default Count for Dumping this Node          !
  NDADR !    Default Starting Address for Dumps of This Node    !


         NDENM = B0     Status Monitoring Enabled for This Node
         NDENL = B1     Loading Enabled for This Node
         NDEND = B2     Dumping Enabled for This Node
         NDFRD = B3     Force Dump on Detected Crash
         NDFRL = B4     Force Reload on Detected Crash
         NDPST = B5     Protocol type has been set
	 NDTOP = B6	Topology monitoring initiated from the node
	 NDDIP = B7	Auto Dump in progress
	 NDLIP = B8	Auto Load in progress
	 NDDOK = B9	Responsible for dumping thhe NIB
	 NDLOK = B10	Responsible for loading the NIB


         .VN20F = 0     RSX20F Queued Protocol
         .VNMCB = 1     NSP
         .VNDDC = 2     DDCMP
         .VNCNL = 4     Controller Loopback
         .VNCBL = 5     Cable Loopback


         .CP8 = 0       PDP-8
         .CP11 = 1      PDP-11
         .CP20 = 2      DECSYSTEM-10/20
                                                     Page 10

        Name:  PGMTAB

        Description:  This table  contains  the  information
                necessary  to  load  a  remote  CPU across a
                given device.  Each  entry  is  PGLEN  words
                long.   An  entry  is  made whenever the SET
                SECONDARY-LOAD-FILE     or      the      SET
                TERTIARY-LOAD-FILE command is issued.

        ! PGLDV                     ! PGCPU                     !
        ! Load Device Type (.DTXXX) !     CPU Type (.CPXXX)     !
        ! PGPGM                     ! PGFIL                     !
        !   Program Type (.PTXXX)   !   Address of File Spec    !


         .DTP11 = 0     DP11
         .DTU11 = 2     DU11
         .DTL1E = 4     DL11E
         .DTQ11 = 6     DQ11
         .DTA11 = 8     DA11A
         .DTDUP = 10    DUP11
         .DTDMC = 12    DMC11
         .DTDLV = 14    DLV11
         .DTL1A = 16    DL11A
         .DTKL8 = 18    KL8J
         .DTDTE = 20    DTE20
         .DTDV1 = 22    DV11
         .DTKDP = 28    KMC11/DUP11
         .DTKDZ = 30    KMC11/DZ11


         .CP8 = 0       PDP-8
         .CP11 = 1      PDP-11
         .CP20 = 2      DECSYSTEM-10/20


         .PTSLD = 0     Secondary Loader
         .PTTLD = 1     Tertiary Loader
         .PTOPS = 2     Operating System (Primary Load File)
         .PTSDM = 3     Secondary Dump File
         .PTTDM = 4     Tertiary Dump File