Trailing-Edge
-
PDP-10 Archives
-
BB-H240E-BM_1985
-
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.