Google
 

Trailing-Edge - PDP-10 Archives - bb-h240e-bm_decnet-20_v4_0_dist - documentation/decnet.bwr
There are 17 other files named decnet.bwr in the archive. Click here to see a list.



             Beware File for DECnet-20 V4.0, TOPS-20 V6.1









                      DECnet-20 V4.0 Beware File
                             TOPS-20 V6.1


                              24 Sep 85


              DECnet-20 V4.0, TOPS-20 Version 6.1(7030)



                              Revision 4



COPYRIGHT (C) DIGITAL EQUIPMENT CORPORATION 1976,  1985.   ALL  RIGHTS
RESERVED.

THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND  COPIED
ONLY  IN  ACCORDANCE  WITH  THE  TERMS  OF  SUCH  LICENSE AND WITH THE
INCLUSION OF THE ABOVE COPYRIGHT NOTICE.  THIS SOFTWARE OR  ANY  OTHER
COPIES  THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY
OTHER PERSON.  NO TITLE TO AND OWNERSHIP OF  THE  SOFTWARE  IS  HEREBY
TRANSFERRED.

THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE  WITHOUT  NOTICE
AND  SHOULD  NOT  BE  CONSTRUED  AS  A COMMITMENT BY DIGITAL EQUIPMENT
CORPORATION.

DIGITAL ASSUMES NO RESPONSIBLITY FOR THE USE  OR  RELIABILITY  OF  ITS
SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.
Beware File for DECnet-20 V4.0, TOPS-20 V6.1                    Page 2
                                                             24 Sep 85


                               CONTENTS
                                of the
           DECnet-20 V4.0 Beware File,  TOPS-20 V6.1(7030)



        1.0     NFT and FAL  . . . . . . . . . . . . . . . . . . . . 4
        2.0     DECnet Features and Restrictions . . . . . . . . . . 4
        2.1       Phase II Communication . . . . . . . . . . . . . . 4
        2.2       No Flow Control  . . . . . . . . . . . . . . . . . 4
        2.3       MCB supports DECnet Phase III  . . . . . . . . . . 4
        2.4       Versions of Associated Products  . . . . . . . . . 5
        2.5       Privileged Object Types  . . . . . . . . . . . . . 5
        2.6       Restriction on Task Names  . . . . . . . . . . . . 5
        2.7       Network Topology Software Interrupt  . . . . . . . 5
        2.8       Elective Ethernet End Node . . . . . . . . . . . . 5
        2.9       Network Management Articles  . . . . . . . . . . . 6
        2.9.1       Unrecognized Frame Destination counter . . . . . 6
        2.9.2       LOOP CIRCUIT NI-0-0 Warning  . . . . . . . . . . 6
        2.9.3       Ethernet LOAD NODE Warning . . . . . . . . . . . 6
        2.9.4       Downline Load of DECnet Nodes  . . . . . . . . . 7
        2.9.5       Terminal Server Diagnostic Loads . . . . . . . . 7
        2.9.6       DECnet Network Management Event Logger . . . . . 8
        2.9.7       DTESUI, DN20ST and DTETPR BUGINFs  . . . . . . . 8
        2.9.8       MCB DECnet Events  . . . . . . . . . . . . . . . 8
        2.9.9       VMS DECnet Events  . . . . . . . . . . . . . . . 9
        3.0     Information on the DECnet Package  . . . . . . . .  11
        3.1       The <DN20> Directory on the DECnet Distribution 
                  Tape . . . . . . . . . . . . . . . . . . . . . .  11
        3.2       DECnet Source Tapes  . . . . . . . . . . . . . .  11
        4.0     Beware Entries for Remote Terminals  . . . . . . .  11
        4.1       SET HOST Command . . . . . . . . . . . . . . . .  11
        4.2       Making HOST connections to VMS . . . . . . . . .  11
        4.3       NRT connections from non-TOPS-20 systems . . . .  12
        4.3.1       Segment size increased . . . . . . . . . . . .  12
        4.3.2       Parity removed on remote terminal links  . . .  12
        4.4       TOPS-20's CTERM-SERVER . . . . . . . . . . . . .  12
        4.5       VMS V4.0 . . . . . . . . . . . . . . . . . . . .  12
        4.6       RSX-11M+ . . . . . . . . . . . . . . . . . . . .  13
        5.0     Warning for 36-bit Mode DECnet Links . . . . . . .  13
        5.1       TOPS-20 V5.1 . . . . . . . . . . . . . . . . . .  13
        5.2       TOPS-20 V6.0 . . . . . . . . . . . . . . . . . .  14


APPENDIX A      NETWORK MANAGEMENT EVENT LOGGER

        A.1     The DECNET event logger  . . . . . . . . . . . . . A-1
        A.2     The three logging sinks  . . . . . . . . . . . . . A-3
        A.2.1     The LOGGING CONSOLE  . . . . . . . . . . . . . . A-4
        A.2.2     The LOGGING FILE . . . . . . . . . . . . . . . . A-4
        A.2.3     The LOGGING MONITOR  . . . . . . . . . . . . . . A-5
        A.3     Selecting what events to report  . . . . . . . . . A-5
        A.4     The SHOW LOGGING command . . . . . . . . . . . . . A-6
        A.5     Event logger and system startup  . . . . . . . . . A-7
Beware File for DECnet-20 V4.0, TOPS-20 V6.1                    Page 3
                                                             24 Sep 85


        A.6     Using the event logger . . . . . . . . . . . . . . A-7
        A.7     Event records lost . . . . . . . . . . . . . . . . A-7
        A.8     Implementation details . . . . . . . . . . . . . . A-8
        A.9     MCB events . . . . . . . . . . . . . . . . . . . . A-8
        A.10    Logging to remote nodes  . . . . . . . . . . . . . A-9
        A.11    Filtering on entity ID's . . . . . . . . . . . .  A-10


APPENDIX B      EVENT MESSAGE FORMAT
Beware File for DECnet-20 V4.0, TOPS-20 V6.1                    Page 4
NFT and FAL                                                  24 Sep 85


1.0  NFT and FAL

Updated versions of NFT and FAL are included on the DECnet tape.



2.0  DECnet Features and Restrictions

2.1  Phase II Communication

TOPS-20 V6.1 supports DECnet Phase IV and thus  does  not  communicate
with DECnet Phase II nodes.


                                 NOTE

               TOPS-20  DECSYSTEM-2020s  are  Phase  II
               DECnet   nodes   and   thus   will   not
               communicate with TOPS-20 V6.1.





2.2  No Flow Control

TOPS-20 V6.1 DECnet uses "No Flow Control" by default.  This  normally
gives  better  performance  than  "Segment Flow Control", the previous
default.  Since most DECnet releases have until recently used  Segment
or  Message  Flow  Control,  it  is  possible  that  the user may find
problems  when  using  V6.1   to   communicate   with   older   DECnet
implementations.  To use segment flow control, enter the command

                 DECNET DEFAULT-FLOW-CONTROL SEGMENT

into the 6-1-CONFIG.CMD startup configuration file.



2.3  MCB supports DECnet Phase III

The MCB software in the DN20 supports Phase III DECnet.   This  should
present  no  problem in a single-area network of fewer than 256 nodes.
In a multi-area Phase IV network, TOPS-20 V6.1 will only  be  able  to
access  the entire Phase IV network through the NIA20 or the CI20, not
through the DN20.
Beware File for DECnet-20 V4.0, TOPS-20 V6.1                    Page 5
DECnet Features and Restrictions                             24 Sep 85


2.4  Versions of Associated Products

Please note that versions of  the  MCB  (DECnet  code  for  the  DN20)
shipped  with  TOPS-20  versions  5.1  and  6.0  will still work under
TOPS-20 V6.1, but that previous versions of NMLT20 and NCPTAB.MAC will
not work under TOPS-20 V6.1.  Please note also that there are required
changes to the NCP command files which start DECnet in the host and in
the DN20.



2.5  Privileged Object Types

TOPS-20  V6.1  implements  the  Digital  Network  Architecture   (DNA)
restriction  that  only privileged users can open passive (SRV:) links
with object numbers from 1 to 127.  This may force some user  programs
to choose new object numbers.



2.6  Restriction on Task Names

In previous releases, a user program was allowed  to  specify  both  a
non-zero  object  type and a task name in a network logical link name.
For example, DCN:NODE-63.DTR was allowed, but is no longer.

This change was made  in  order  to  be  compatible  with  the  DECnet
architecture and other DECnet implementations.

We suggest  that  programs  now  use  DCN:NODE-TASK-63DTR  instead  of
DCN:NODE-63.DTR.



2.7  Network Topology Software Interrupt

Under Phase IV TOPS-20 DECnet, the Network Topology Software Interrupt
will  only be given on non-endnode systems for topology changes within
the local routing area.  This could cause some programs to miss DECnet
opportunities.

A system which does  not  elect  Ethernet  Endnode  status  and  which
participates  in a single-area network should see no difference in the
NTC PSI.



2.8  Elective Ethernet End Node

TOPS-20  V6.1  defaults  to  being  a  routing   DECnet   node.    For
non-Ethernet  circuits  this  default  imposes  little overhead on the
system.  DECnet routing on Ethernet circuits imposes  little  overhead
if there are few routing nodes on the Ethernet.
Beware File for DECnet-20 V4.0, TOPS-20 V6.1                    Page 6
DECnet Features and Restrictions                             24 Sep 85


The overhead imposed by DECnet routing on Ethernet circuits grows more
than  linearly  with  the  number  of  DECnet routers on the Ethernet.
Thus, it is wise to configure as few routing nodes on an  Ethernet  as
is  practical.   If  the  NIA20  is to be the only DECnet circuit, the
system manager should use the SETSPD command DECNET ROUTER-ENDNODE  to
reduce routing overhead on the Ethernet and on the 20.

A rule of thumb is that there should be no more than 10 routing  nodes
on a single Ethernet.



2.9  Network Management Articles

2.9.1  Unrecognized Frame Destination counter

The NCP  command  SHOW  CIRCUIT  NI-0-0  COUNTERS  returns  a  counter
entitled   Unrecognized  Frame  Destination.   Please  disregard  this
counter as presently implemented.

The NIA20 microcode counts an "Unrecognized Frame  Destination"  every
time a received message passes the hardware address filter but not the
microcode filter.  This happens when  someone  sends  to  a  multicast
address  for which we are not enabled.  The hardware filter passes all
multicast messages;  the NIA20 microcode filters  multicast  messages.
This  is  not  an  error  and  the  counter  should  have no effect on
performance.



2.9.2  LOOP CIRCUIT NI-0-0 Warning

The NCP command LOOP CIRCUIT NI-0-0 may produce  LLMILF  BUGINFs  when
looping  to a DEUNA.  The DEUNA is the unibus to Ethernet adapter used
on VAXs and PDP-11s.  The BUGINFs are caused by a DEUNA responding  to
the  loop  request  with  a  message that contains an invalid function
code.  This is a known problem with the DEUNAs and does  not  indicate
an error in the network.



2.9.3  Ethernet LOAD NODE Warning

The LOAD NODE command  should  not  be  used  for  nodes  on  Ethernet
circuits.  This command will result in an NML request that monopolizes
NMLT20 until it times out.  Instead, the  TRIGGER  command  should  be
used  where  applicable  or the remote console facility can be used to
initialize a load operation.  For the Ethernet  Terminal  Server,  use
the  TRIGGER  command;   for the DECserver-100, use the remote console
facility and the DECserver-100 command INIT.
Beware File for DECnet-20 V4.0, TOPS-20 V6.1                    Page 7
DECnet Features and Restrictions                             24 Sep 85


2.9.4  Downline Load of DECnet Nodes

When a DECnet node initializes an Ethernet  circuit,  it  changes  its
Ethernet  address  from  the  factory-installed  address to an address
whose low-order 16 bits are the same as its DECnet node number.   Thus
the  DECnet  node  has  one  address when first powered up and another
after DECnet has started.

If this node is a dependent  node  to  be  downline  loaded  over  the
Ethernet,  for  example an RSX11S system, its first load requests will
have the factory-installed address in the boot requests  but  it  will
have  the  DECnet  address  in  any  reboot  requests after DECnet has
started.

A succesful workaround is to use NCP to set the  hardware  address  of
the  dependent DECnet node to its factory-installed address when first
booting the dependent node, then to use NCP  to  change  the  hardware
address   to  the  DECnet  address  after  the  dependent  system  has
initialized DECnet.  The following shows  how  to  create  the  DECnet
Ethernet address from the DECnet area and node number:

     1.  Convert the DECnet area.node number to a 16  bit  value  with
         the  area  number in the high order (leftmost) 6 bits and the
         node number in  the  low  order  (rightmost)  10  bits.   For
         example,  node 7.107 would convert to the 16 bit binary value
         of 000 111 000 001 101 001 (octal:  070153).   Remember  that
         the area and node numbers are decimal.

     2.  Group the sixteen bit value as 4 hexidecimal  digits  in  two
         pairs.  The above value would become 1C 6B.

     3.  Invert the two hexidecimal numbers and  append  them  to  the
         hexidecimal  value  AA000400.   This  will produce the DECnet
         Ethernet address.  In the example, the address 7.107 would be
         AA0004006B1C.


A future version of NMLT20 will try to match both the hardware address
and the DECnet address for any boot requests.



2.9.5  Terminal Server Diagnostic Loads

After Ethernet Terminal Server diagnostics have completed, TOPS-20  is
documented   to   load   the   normal  system  image  into  the  DECSA
automatically.  In this release, however, the operator  must  use  the
NCP  TRIGGER  command  to  trigger  a  normal  system  load  once  the
diagnostics have stopped running.
Beware File for DECnet-20 V4.0, TOPS-20 V6.1                    Page 8
DECnet Features and Restrictions                             24 Sep 85


2.9.6  DECnet Network Management Event Logger

TOPS-20 now supports the  full  implementation  of  the  DECnet  Event
Logger.   DECnet  events  can be filtered and distributed to the SPEAR
file, to operators running OPR,  and  to  application  programs.   The
default  is to log all known events in the SPEAR file only.  If you do
not wish any or certain events to go to the SPEAR file,  you  need  to
add  commands in your network startup files to modify the behaviour of
the event logger.  The NCP commands to control the  event  logger  are
defined in the DECnet-20 System Managers Guide.  We recommend that you
study  the  documentation,  since  event  processing   can   be   very
CPU-consuming in a large dynamic network.

An appendix to this beware file describes the  event  logger  in  more
detail.



2.9.7  DTESUI, DN20ST and DTETPR BUGINFs

When TOPS-20 and the MCB reinitialize protocol across the DTE, TOPS-20
outputs  one or both of the following BUGINFs:  DTESUI, DN20ST.  These
BUGINFs only indicate that the  protocol  has  been  interrupted,  not
necessarily  that  the MCB has stopped running.  DTETPR indicates that
the DN20 is being reloaded.

In order to suppress DTESUI, DN20ST and DTETPR BUGINFs, set  the  cell
DTBUGX in STG to zero, either in STG.MAC or with DDT.  It is defaulted
to 1 in the monitor we ship to be compatible with  previous  monitors.
DTBUGX has no effect on BUGINFs due to code other than the MCB running
in the DN20 front end (eg, DN6x IBMCOMM).



2.9.8  MCB DECnet Events

You only need to read this section if you are  interested  in  sending
the  DECnet  events  generated  by  an MCB to something other than its
TOPS20 host.

There is a problem in the V5.1 MCB with regard to DECnet events.   The
events generated by the MCB use an improper size of 2 bytes for one of
the fields when the corporate architecture prescribes a  single  byte.
This did not cause a problem with the V5.1 NMLT20 since it was written
to expect the 2 byte field.

We have decided not to correct this in V6.1, since that will  simplify
backwards  compatibility  with  V5.1  and  V6.0.  We may fix this at a
later time when V5.1 is no longer supported and has been  replaced  by
V6.1.   This  means  that  you will have a problem if you want to send
your MCB events to something other than a TOPS-10 or TOPS-20 host.
Beware File for DECnet-20 V4.0, TOPS-20 V6.1                    Page 9
DECnet Features and Restrictions                             24 Sep 85


If you plan to send MCB events to other hosts, you  need  to  apply  a
patch.   Below  you will find a patch for both the V5.1 and V6.1 MCBs.
You do not need to apply any patches to the V6.1 NMLT20, since it  has
been  changed  to understand both sizes of the field.  However, if you
do apply the MCB patch and then revert to TOPS20  V5.1,  you  need  to
'unpatch' the MCB since the V5.1 NMLT20 requires the old wrong format.

;This patch is for the 6.1 MCB



 TOPS-20 Command processor 6.1(7)
@ena
$ddt11
DDT11 7E(120)

Input: system:d2102a.sys/mcbsys
[56p core]
[60p core]
[61p core]
[203p core]
 highest location is 637003

;This patch will turn the 2 byte field into a single byte one
160500/   MOVB 1(R1),(R5)+   nop
160502/   HALT    nop
;(Patch at 160502 and 160504 in the 5.1 MCB)

;This patch will send the event to all sinks (console,file,monitor)
160162/   RTI    =2   7
;(Patch at 160164 in the 5.1 MCB)

$p
FILE: d2102a.sys/mcbsys
File DSK:D2102A.SYS[4,130]  written

^C


If you plan to change the host for an MCB, you  need  also  to  change
your  MCB  startup commands to set the host to the desired other node.
After a reload, the MCB will use the new host.



2.9.9  VMS DECnet Events

You may find many event records of the following form:
Event type 3.0  Invalid message
From node <nodenumber>. (<nodename>), occurred <date> <time>

  Message = 48 / nnn / nnn / 00 00
  Parameter #2 = nnnn
Beware File for DECnet-20 V4.0, TOPS-20 V6.1                   Page 10
DECnet Features and Restrictions                             24 Sep 85


These records indicate that TOPS-20 has  detected  an  illegal  DECnet
Disconnect  Confirm  message, usually from a VMS V4.0 system.  The VMS
engineering group intends to fix this in a  future  release.   In  the
meantime,  you  may  want to filter these events.  The errors cause no
harm to either the system or to the user's logical link.
Beware File for DECnet-20 V4.0, TOPS-20 V6.1                   Page 11
Information on the DECnet Package                            24 Sep 85


3.0  Information on the DECnet Package

3.1  The <DN20> Directory on the DECnet Distribution Tape

The DN20 directory is used in building the MCB for the Front End.  The
contents  matches  the versions of the software available in Autopatch
Tape 10.  This supercedes the version of the MCB that was used in  the
DECnet V4.0 field test.  The only difference is that the field test of
DECnet V4.0 used an older version of the XPE.TSK file.   This  version
has  been  renamed  OLD-XPE.*.   It is on the tape only to provide the
possibility of rebuilding the field tested MCB.



3.2  DECnet Source Tapes

The TOPS-20 part of DECnet is on the TOPS-20 monitor source tape.  The
Sources  for NMLT20 are on one of the two DECnet Source tapes.  NMLT20
requires BLISS-36 in order to be built from these  sources.   The  MCB
related  directories  (MCB.*)  on  the  source  tapes  contain  source
information for the MCB and the utilities required to build  the  MCB.
It  should  be  noted  that  this  is  for "information only" and that
Digital does not warrent that the MCB executable image  can  be  built
using these source files.



4.0  Beware Entries for Remote Terminals

4.1  SET HOST Command

The System Manager should set the system-wide logical  name  NRT:  for
the   SET   HOST  command.   The  SET  HOST  command  first  runs  the
CTERM-SERVER which attempts to connect to a CTERM HOST on  the  target
system.  If this fails, the EXEC will run the program indicated by the
logical name NRT:.  This program is normally SYS:SETHOST.EXE (talks to
20s)  or  the unsupported SYS:HOST.EXE (talks to pre-CTERM VMS and RSX
systems as well as 20s).



4.2  Making HOST connections to VMS

The  unsupported  HOST  program  has  been   changed   to   initialize
connections  to  VMS  more  completely.   HOST  now sets many terminal
characteristics just after making  a  connection,  so  the  connection
appears  to  take  noticeably  longer  than in the past.  The terminal
characteristics handling, however, will be improved.
Beware File for DECnet-20 V4.0, TOPS-20 V6.1                   Page 12
Beware Entries for Remote Terminals                          24 Sep 85


4.3  NRT connections from non-TOPS-20 systems

4.3.1  Segment size increased

User applications which  make  virtual  terminal  connections  to  the
TOPS-20 NRT object type from non-TOPS-20 systems may have trouble with
TOPS-20  V6.1.   NRT  is  only  supported  in   TOPS-20   to   TOPS-20
connections.   There  should  be  no  problem between TOPS-20 systems,
version 5.1 or later.

Previous versions of TOPS-20 sent a maximum of 64 bytes  in  a  single
NRT  output  message.   V6.1  will  send a maximum of 500 bytes or the
segment size, whichever is smaller, to  improve  performance.   If  an
application requires the old 64 byte maximum, patch the cell NRTMAX to
64.



4.3.2  Parity removed on remote terminal links

Previous releases of TOPS-20 sent 7-bit ASCII  with  parity  over  NRT
links.   In  order  to  avoid confusing 8-bit ASCII terminals, TOPS-20
V6.1 does not set parity on NRT, CTERM or LAT links.



4.4  TOPS-20's CTERM-SERVER

The source file for CTERM-SERVER is called  SERVER.MAC.   The  shorter
name helps compiling and linking.

This is the list of known CTERM-SERVER bugs:

     1.  The CTERM server program will not currently pass Null  or  ^V
         (quote) characters to the remote host.

     2.  Terminal  pause  on  character  SPACE  (TERMINAL   PAUSE   on
         END-OF-PAGE  MODE) does not currently work on the remote host
         with CTERM-SERVER.

     3.  The VMS V4.0 command-line editor will not work on a  terminal
         connected via CTERM-SERVER.




4.5  VMS V4.0

There are some known bugs in RTPAD (SET  HOST)  under  VMS  V4.0  when
setting  host  to  a  TOPS-20  system.   These bugs are expected to be
addressed in the next point releases of  VMS.   These  are  the  known
bugs:
Beware File for DECnet-20 V4.0, TOPS-20 V6.1                   Page 13
Beware Entries for Remote Terminals                          24 Sep 85


     1.  Setting TERMINAL PAUSE on END-OF-PAGE on TOPS-20  will  force
         an image error exit under VMS.

     2.  The character escape ESC is echoed as "$" when  connected  to
         TOPS-20 under CTERM.

     3.  Terminal recognition via TTYINI  will  not  work  unless  the
         TERMINAL NO RAISE command is issued first.

     4.  Normal exit from SET HOST  may  leave  the  VMS  terminal  in
         NOSYNC,  NOlowercase mode;  doing a SET TERMINAL /INQUIRE may
         be necessary to reestablish terminal settings.

     5.  VMS conventions apply to  many  TOPS-20  control  characters;
         e.g.  EXIT may be printed after ^Z;  ^X will be turned into a
         ^U and will clear the typeahead buffer.




4.6  RSX-11M+

The user may find a very similar set of bugs in RSX-11M+ when  setting
host to a TOPS-20 system.



5.0  Warning for 36-bit Mode DECnet Links

You only need to read this section if you have  an  application  which
uses  36-bit  byte mode task-to-task DECnet transfers.  NFT and FAL do
not use this mode, even for 36-bit byte files.

DECnet-20 in monitors before V6.1 could transfer files in 36-bit  byte
mode to other TOPS-20 systems of the same version, but they have a bug
which is only seen when the remote system has  a  larger  buffer  size
than  the  V5.1  system.   TOPS-20  V6.1  uses  larger buffer sizes by
default, so the following patch may be needed at your site.



5.1  TOPS-20 V5.1

Any site wishing to send files in 36-bit  byte  mode  between  systems
running TOPS-20 V5.1 and TOPS-20 V6.1 must install the following patch
in the 5.1 system.

(In place of the character $ below, type the <ESC> character.)

@ena
$get system:monitr.exe
$ddt
nspsrv$:
dosrv1/  DPB T2,NSPFRK+46     trn
Beware File for DECnet-20 V4.0, TOPS-20 V6.1                   Page 14
Warning for 36-bit Mode DECnet Links                         24 Sep 85


dosrv1+4/ MOVE CX,T2(T1)    $<dpb t2,nspfrk+46$1>
^Z
$Save system:monitr.exe


                                 NOTE

               If  the   effective   address   of   the
               instruction  at DOSRV1 is not NSPFRK+46,
               substitute the  value  in  your  monitor
               into the patch line at DOSRV1+4.

               If you do not understand how to  install
               this patch, you may wish to contact your
               local software specialist.





5.2  TOPS-20 V6.0

Any site wishing to send files in 36 bit  byte  mode  between  systems
running TOPS-20 V6.0 and TOPS-20 V6.1 must install the following patch
in the TOPS-20 V6.0 system.

(In place of the character $ below, type the <ESC> character.)

@enable
$get system:monitr.exe
$ddt
nspsrv$:
dosrv1/  DPB T2,NSPFRK+32     trn
dosrv1+4/ MOVSI CX,STS      $<dpb t2,nspfrk+32$1>
^z
$save system:monitr.exe
$


                                 NOTE

               If  the   effective   address   of   the
               instruction  at  DOSRV1 is not NSPFRK+32
               substitute the  value  in  your  monitor
               into the patch line at DOSRV1+4.

               If you do not understand how to  install
               this patch, you may wish to contact your
               local software specialist.











                              APPENDIX A

                   NETWORK MANAGEMENT EVENT LOGGER



A.1  The DECNET event logger

DECnet generates an event message when an error or  something  unusual
occurs  during  operation.   The  event  message  contains the type of
event, where it occurred and the time of the event.  Example:

22:46:30          -- Message from DECnet event logger --

DECNET Event type 4.15, Adjacency up
Event came from node 7.142 (GIDNEY), occurred 8-JAN-1985 22:46:28

  Circuit DTE-0-1

  Node = 7.143 (GIDDN) 


Each event has an identification of the form 4.15.  The  first  number
(4)  is  called  the event class and defines which part of DECnet that
generated the event.  In particular, 4 stands for the  routing  layer.
The  second  number  (15)  is called the event type and identifies the
particular event.  Together 4.15 means "Adjacency up, reported by  the
routing layer".

Associated with most events is a DECnet entity.  A DECnet  entity  may
be  a node, a circuit or a line.  In this particular event, the entity
is the DTE-0-1 circuit.  It means that the "adjacency up" was detected
on the DTE circuit.

In addition, there may be one or more lines of additional  data.   For
this  event,  the  additional  data  informs  us  that  node GIDDN was
detected at the other end of the DTE circuit.

Here is the full list of all events.  The ones TOPS-20  will  generate
are flagged with a *.  TOPS-20 can however receive and log all defined
events.  (We will see in a moment that events can be sent  to  (logged
at) other nodes.)
NETWORK MANAGEMENT EVENT LOGGER                               Page A-2
The DECNET event logger                                      24 Sep 85



List of all events defined in DEcnet phase IV network management
================================================================

Event   Tops-20 Entity          Name
-----   ------  ------          ----

  Network management layer
0.0     *       -               Event records lost
0.1             Node            Automatic node counters
0.2             Line            Automatic line counters
0.3     *       Circuit         Automatic service
0.4             Line            Line counters zeroed
0.5             Node            Node counters zeroed
0.6             Circuit         Passive loopback
0.7     *       Circuit         Aborted service request
0.8     *       Any             Automatic counters
0.9     *       Any             Counters zeroed

  Session control layer
2.0             -               Local node state change
2.1             -               Access control reject

  End to end communications layer (NSP)
3.0     *       -               Invalid message
3.1     *       -               Invalid flow control
3.2     *       Node            Data base reused

  Routing layer
4.0     *       -               Aged packet loss
4.1     *       Circuit         Node unreachable packet loss
4.2     *       Circuit         Node out-of-range packet loss
4.3             Circuit         Oversized packet loss
4.4     *       Circuit         Packet format error
4.5     *       Circuit         Partial routing update loss
4.6     *       Circuit         Verification reject
4.7     *       Circuit         Circuit down, circuit fault
4.8     *       Circuit         Circuit down
4.9     *       Circuit         Circuit down, operator initiated
4.10    *       Circuit         Circuit up
4.11    *       Circuit         Initialization failure, line fault
4.12    *       Circuit         Initialization failure, software fault
4.13    *       Circuit         Initialization failure, operator fault
4.14    *       Node            Node reachability change
4.15    *       Circuit         Adjacency up
4.16    *       Circuit         Adjacency rejected
4.17            Area            Area reachability change
4.18    *       Circuit         Adjacency down
4.19    *       Circuit         Adjacency down, operator initiated

  Data link layer
5.0     *       Circuit         Locally initiated state change
5.1     *       Circuit         Remotely initiated state change
5.2             Circuit         Protocol restart received in maintenance mode
NETWORK MANAGEMENT EVENT LOGGER                               Page A-3
The DECNET event logger                                      24 Sep 85


5.3     *       Circuit         Send error threshold
5.4     *       Circuit         Receive error threshold
5.5     *       Circuit         Select error threshold
5.6     *       Circuit         Block header format error
5.7             Circuit         Selection address error
5.8             Circuit         Streaming tributary
5.9             Circuit         Local buffer too small
5.10            Module          Restart (X.25 protocol)
5.11            Module          State change (X.25 protocol)
5.12            Module          Retransmit maximum exceeded
5.13            Line            Initialization failure
5.14            Line            Send failed
5.15            Line            Receive failed
5.16            Line            Collision detect check failed
5.17            Module          DTE up (X.25)
5.18            Module          DTE down (X.25)

  Physical link layer
6.0             Line            Data set ready transition
6.1             Line            Ring indicator transition
6.2             Line            Unexpected carrier transition
6.3             Line            Memory access error
6.4             Line            Communications interface error
6.5             Line            Performance error



                                 NOTE

               All events are listed and  explained  in
               the DECnet-20 System Managers Guide.





A.2  The three logging sinks

An event can be reported (logged) in three different  ways.   We  call
each "a logging sink".  The three logging sinks are:

      o  LOGGING CONSOLE

      o  LOGGING FILE

      o  LOGGING MONITOR


The system manager controls the event logger with  network  management
through  NCP.   He/she  can  decide  what  sinks that are active, i.e.
turned on.  If so desired, a single event can be  logged  at  multiple
sinks.  The three sinks are addressed in NCP as:

        NCP> SET LOGGING CONSOLE  ...
NETWORK MANAGEMENT EVENT LOGGER                               Page A-4
The three logging sinks                                      24 Sep 85


        NCP> SET LOGGING FILE ...
        NCP> SET LOGGING MONITOR ...

or if the same operation is desired on all sinks

        NCP> SET KNOWN LOGGING ...


Whether a sink is enabled or not is determined by the STATE parameter.
Example:  to enable the logging console do

        NCP> SET LOGGING CONSOLE STATE ON

or to disable all logging sinks do

        NCP> SET KNOWN LOGGING STATE OFF




A.2.1  The LOGGING CONSOLE

The logging console is really  the  OPR  program.   If  this  sink  is
active,  then  the events are formatted and sent to all running OPR's.
A sample of the output can be seen at the top of this document.

Note that if the logging console is enabled, then ALL OPR's receive  a
copy  of  the  event  message.  If you wish to disable the output at a
certain terminal, you can

        OPR> DISABLE OUTPUT-DISPLAY (OF) DECNET-EVENT-MESSAGES


There is also a corresponding ENABLE command.



A.2.2  The LOGGING FILE

The  logging  file   is   always   the   system   error   file,   i.e.
SERR:ERROR.SYS.  If this sink is enabled, then a binary version of the
event message is put into the error file.

The  logged  events  can  then  be  retrieved  with  SPEAR.    Example
retrieving network errors:

509. 10:45:23  DECNET Event type 3.2  Data base reused
                    From node 7275. (RONCO)
                    occurred 4-APR-1985 10:41:47.877
516. 11:25:18  DECNET Event type 3.0  Invalid message
                    From node 7275. (RONCO)
                    occurred 4-APR-1985 10:53:46.549
517. 11:25:18  DECNET Event type 0.0  Event records lost
                    From node 7275. (RONCO)
NETWORK MANAGEMENT EVENT LOGGER                               Page A-5
The three logging sinks                                      24 Sep 85


                    occurred 4-APR-1985 11:03:53.738
535. 12:06:43  DECNET Event type 0.3  Automatic line service
                    From node 7275. (RONCO)
                    occurred 24-JAN-1985 17:06:26




A.2.3  The LOGGING MONITOR

The logging monitor provides a way to either send  events  to  a  user
program,  or  to  write  them  to  a file the user specifies.  In both
cases, the binary version of the event message is used.  The format of
the event message (the same for all DECnet implementations) is defined
in appendix A.

The destination of the logging monitor events is  set  with  the  NAME
parameter.  Example:

        NCP> SET LOGGING MONITOR NAME DCN:GIDNEY-TASK-LOGMON

to send the events to a user program using DECnet or

        NCP> SET LOGGING MONITOR NAME PS:<OPERATOR>LOGGING-MONITOR.BIN

to write the event messages to a file.



                                 NOTE

               You cannot redirect the console or  file
               by setting NAME.





A.3  Selecting what events to report

The system manager may choose what events  to  log  for  each  logging
sink.  Here are a few examples:

To log all events known to TOPS-20 to the logging file:

        NCP> SET LOGGING FILE KNOWN EVENTS

To log all routing layer events to the console:

        NCP> SET LOGGING CONSOLE EVENT 4.*

To log network management events 0,1,2,3,5,7,8,9 to all sinks:

        NCP> SET KNOWN LOGGING EVENT 0.0-3,5,7-9
NETWORK MANAGEMENT EVENT LOGGER                               Page A-6
Selecting what events to report                              24 Sep 85



The latter could also have been accomplished with the sequence:

        NCP> SET KNOWN LOGGING EVENT 0.0-9
        NCP> CLEAR KNOWN LOGGING EVENT 0.4,6


Note that you can only specify one event class in each event  command.
I.e.  the following command is illegal:

        NCP> SET LOGGING MONITOR EVENT 4.15 , 5.13


If an event is not enabled at any logging sink, it is  filtered  (i.e.
thrown away) by the event logger.



A.4  The SHOW LOGGING command

To inspect the current status of the logging sinks, you  can  use  the
SHOW LOGGING command.  Example:

To show all information stored for the logging console:
        NCP> SHOW LOGGING CONSOLE SUMMARY

and to do the same for all sinks:
        NCP> SHOW KNOWN LOGGING SUMMARY

Here is a sample output of the first command:

NCP>SHOW LOGGING CONSOLE SUMMARY
NCP>
11:26:53        NCP
                Request # 148; Show Logging Summary Completed
                
                Logging = Console
                
                  State = On
                
                  Sink Node = 7.142 (GIDNEY)
                  Events = (Source = any) 0.0-9 
                  Events = (Source = any) 3.0-2 
                  Events = (Source = any) 4.0-4 6-14 16-19 
                  Events = (Source = any) 5.0-31 
                  Events = (Source = any) 6.0-5 
NETWORK MANAGEMENT EVENT LOGGER                               Page A-7
Event logger and system startup                              24 Sep 85


A.5  Event logger and system startup

You now know all the basic commands of the  event  logger.   For  each
logging  sink,  you  can  SET  or  CLEAR  the  STATE,  NAME  and EVENT
parameters.  The event logger initializes itself  with  the  following
commands at startup:

        NCP> SET LOGGING FILE KNOWN EVENT
        NCP> SET LOGGING FILE STATE ON


That is, all events will be logged to the logging file.  If  you  wish
to  change  this  at  system  startup,  you  will  have to add LOGGING
commands to your network startup file.

No events will be logged unless both the STATE is ON, and  some  EVENT
is enabled for the sink.



A.6  Using the event logger

If you have a fairly small and stable network, you may wish to  enable
all events for logging to file and/or console.

If you have a large and dynamic network, you may find that you want to
filter  certain  events.   For  instance,  the  routing  layer, when a
level-1 router, will generate an "adjacency up" event  for  each  node
that  comes  online  on the Ethernet.  If you have many systems on the
Ethernet, and the Ethernet goes offline/online, you will get  a  large
number  of  "adjacency  up"  events that may hide the more interesting
4.7-10 events (Circuit down/up).

Along the same  lines,  you  may  wish  to  filter  event  4.14  (Node
reachability change) if you have a large and dynamic network.

If your system does have a NIA20, we recommend  that  you  enable  all
data  link  layer  events  (5.*).  When they occur, they are typically
caused by a NIA20 hardware anomaly.



A.7  Event records lost

Event messages may be temporarily stored both in the  monitor  and  in
the  NMLT20  program  before being reported.  If there are many events
occurring  at  the  same  time,  the  queues  may  overflow  and   the
consequence  will  be a "lost event".  The "lost event" (0.0) does not
contain any information about what event was lost since more than  one
may  have  been  discarded.  It only tells you that at least one event
was  thrown  away  becuase  of  buffering  problems.    If   you   are
troubleshooting a problem with the help of the event logger, it may be
important to know that some information was  lost  in  a  sequence  of
events.
NETWORK MANAGEMENT EVENT LOGGER                               Page A-8
Event records lost                                           24 Sep 85


If you experience many "lost events" you should examine  your  reports
to find out what event that may be happening frequently.



A.8  Implementation details

The event logger, in particular the logging  console,  is  fairly  CPU
intensive.  You can lower the overhead by filtering more events.

We would also like to draw your attention to an implementation detail.
Assume  that  you  want to disable all events for the logging monitor.
You could accomplish this in two different ways:

        NCP> SET LOGGING CONSOLE STATE OFF
or
        NCP> CLEAR LOGGING CONSOLE KNOWN EVENT


We recommend that you use  the  CLEAR  command.   It  will  lower  the
overhead  more  than  the SET STATE OFF command because of the way the
event logger is implemented.



A.9  MCB events

The MCB will also generate events, but since  it  does  not  have  any
logging sinks of its own, it will send its events to its KL host.  The
MCB does not have  any  event  database,  so  you  cannot  dynamically
disable  or  enable individual events.  However, since the events will
pass through the event filters  on  the  KL  host,  you  can  actually
control the MCB events in the KL instead.

The MCB does not have a clock, and can therefore not include the  time
of  day  in  the  event message.  It will include the uptime which may
help you in determining exactly when a MCB event was generated.

We would like to  point  to  a  potential  problem.   If  the  MCB  is
connected  to  a  VMS system, the VMS system may send routing messages
that are too large for the MCB to process.  The MCB  will  generate  a
4.5 ("Partial routing update loss") event and send it to the KL.  This
may happen very frequently and will cause overhead even if  you  throw
away the 4.5 events as they arrive to the KL.

If this happens, we suggest that you rebuild your MCB and  change  the
static  event  database.   If we assume that you want to disable event
4.5, issue the following command when running  NETGEN  generating  the
MCB:

        NETGEN> PURGE LOGGING FILE EVENT 4.5
        NETGEN> LIST LOGGING FILE EVENT
NETWORK MANAGEMENT EVENT LOGGER                               Page A-9
Logging to remote nodes                                      24 Sep 85


A.10  Logging to remote nodes

In addition to the logging sinks on your node, you can send events  to
other  remote  DECnet  nodes.   For instance, you may want to send all
events from all systems to one  single  node  that  collects  all  the
events in the network.  If we assume that you want to send all network
management events to the logging console on node RONCO:, here  is  the
command to do it:

        NCP> SET LOGGING CONSOLE EVENT 0.* SINK NODE RONCO::


and the result will be that all 0.* events will be sent to the console
on RONCO:  as well as to all other sinks that are enabled.

Here is a sample typeout where both a local logging monitor,  and  two
remote logging monitors are enabled:

NCP>SHOW LOGGING MONITOR SUMMARY KNOWN SINKS
NCP>
11:34:10        NCP
                Request # 156; Show Logging Summary Completed
                
                Logging = Monitor
                
                  State = On
                  Name = GIDNEY:<OPERATOR>LOGGING-MONITOR.BIN
                
                  Sink Node = 7.142 (GIDNEY)
                  Events = (Source = any) 0.0-9 
                  Events = (Source = any) 3.0-2 
                  Events = (Source = any) 4.0-19 
                  Events = (Source = any) 5.0-9 13-16 
                  Events = (Source = any) 6.0-5 
                
                  Sink Node = 7.107 (RONCO)
                  Events = (Source = any) 5.0-31 
                
                  Sink Node = 7.52 (LATOUR)
                  Events = (Source = any) 4.1 
                  Events = (Source = any) 5.0-31 


Note that you have to add 'KNOWN SINKS' to the SHOW command to see all
remote sinks.
NETWORK MANAGEMENT EVENT LOGGER                              Page A-10
Filtering on entity ID's                                     24 Sep 85


A.11  Filtering on entity ID's

Associated with most events is an entity type (see  table  in  section
1).   You  can  enable or disable events depending on what entity type
they are associated with.  For example, if you want to log  event  4.7
only on the Ethernet circuit, do:

        NCP> CLEAR LOGGING CONSOLE EVENT 4.7
        NCP> SET LOGGING CONSOLE EVENT 4.7 CIRCUIT NI-0-0


Event 4.7 (Circuit down) will be logged only if  it  is  the  Ethernet
circuit that went down.

Events that are sent to remote sinks may be qualified in the same way.
The  following  NCP  sequence  illustrates  all  flavors  of the event
logger:

NCP>SET LOGGING CONSOLE STATE ON
NCP>SET LOGGING CONSOLE EVENT 3.0,2
NCP>SET LOGGING CONSOLE EVENT 4.7-10 CIRCUIT NI-0-0
NCP>SET LOGGING CONSOLE EVENT 5.* SINK NODE RONCO::
NCP>SET LOGGING CONSOLE EVENT 4.14 NODE ETHER:: SINK NODE LATOUR::
NCP>SET LOGGING CONSOLE EVENT 4.14 NODE KL2102:: SINK NODE LATOUR::
NCP>SHOW LOGGING CONSOLE SUMMARY KNOWN SINKS
NCP>
11:44:09        NCP
                Request # 167; Show Logging Summary Completed
                
                Logging = Console
                
                  State = On
                
                  Sink Node = 7.142 (GIDNEY)
                  Events = (Source = any) 3.0 2 
                  Events = (Source Circuit = NI-0-0) 4.7-10 
                
                  Sink Node = 7.107 (RONCO)
                  Events = (Source = any) 5.0-31 
                
                  Sink Node = 7.52 (LATOUR)
                  Events = (Source Node = 7.124 (ETHER)) 4.14 
                  Events = (Source Node = 7.120 (KL2102)) 4.14 











                              APPENDIX B

                         EVENT MESSAGE FORMAT



The format of the event message is defined in  the  corporate  network
management specification.  Here is a copy of the definition:

   FUNCTION    SINK     EVENT    EVENT    SOURCE    EVENT     EVENT
     CODE      FLAGS    CODE     TIME      NODE     ENTITY    DATA

   where:

   FUNCTION CODE (1) : B = 1, meaning event log

   SINK FLAGS (1) :  BM  Are flags indicating which sinks are to  receive
                         a copy of this event, one bit per sink.  The bit
                         assignments are:

                         Bit      Sink

                          0     Console
                          1     File
                          2     Monitor

   EVENT CODE (2) : BM Identifies the specific event as follows:

                         Bits        Meaning

                         0-4     Event type
                         6-14    Event class

   EVENT TIME            Is the  source  node  date  and  time  of  event
                         processing.  Consists of:

                         JULIAN   SECOND   MILLISECOND
                         HALF DAY

                         where:

                         JULIAN HALF DAY (2) :  B = Number of  half  days
                                                    since  1 Jan 1977 and
                                                    before  9  Nov   2021
                                                    (0-32767).        For
                                                    example, the  morning
EVENT MESSAGE FORMAT                                          Page B-2
                                                             24 Sep 85


                                                    of Jan 1, 1977 is 0.

                         SECOND (2) :  B =          Second within current
                                                    half day (0-43199).

                         MILLISECOND (2) : B =      Millisecond    within
                                                    current        second
                                                    (0-999).    If    not
                                                    supported, high order
                                                    bit is  set,  remain-
                                                    der  are  clear,  and
                                                    field is not  printed
                                                    when   formatted  for
                                                    output.

   SOURCE NODE           Identifies the source node.  It consists of:

                         NODE     NODE
                         ADDRESS  NAME

                         where:

   NODE ADDRESS (2) :  B = Node address

   NODE NAME (I-6) :  A = Node name, 0 length, if none.

   EVENT ENTITY          Identifies the entity involved in the event, as
                         applicable.  Consists of:

                         ENTITY ENTITY
                          TYPE    ID

                         where:

                         ENTITY TYPE (2) :  B   Represents  the  type  of
                                                entity.    A   -1   value
                                                indicates no  entity.   A
                                                value  >= 0 is the entity
                                                type and is  followed  by
                                                the   entity  id  in  its
                                                usual format.

   EVENT DATA (*) :  B Is event specific data, zero or more data  entries
                       as  defined  for NICE data blocks, parameter types
                       according to event class.