Trailing-Edge
-
PDP-10 Archives
-
TOPS-20_V6.1_DECnetDistr_7-23-85
-
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, Field Test Tape 6
DECnet-20 Beware File
Field Test Tape 6
17 Jul 85
TOPS-20 Version 6.1(6763)
Revision 3
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, Field Test Tape 6 Page 2
17 Jul 85
CONTENTS
of the
TOPS-20 Beware File, V6.1
V6-Series Field Test Tape #6
1.0 New CTERM-SERVER . . . . . . . . . . . . . . . . . . 3
2.0 RMS V3 . . . . . . . . . . . . . . . . . . . . . . . 3
3.0 DECnet Features and Restrictions . . . . . . . . . . 3
3.1 Phase II Communication . . . . . . . . . . . . . . 3
3.2 No Flow Control . . . . . . . . . . . . . . . . . 3
3.3 MCB supports DECnet Phase III . . . . . . . . . . 4
3.4 Versions of Associated Products . . . . . . . . . 4
3.5 MCB DECnet Events . . . . . . . . . . . . . . . . 4
3.6 VMS DECnet Events . . . . . . . . . . . . . . . . 5
3.7 Unrecognized Frame Destination counter . . . . . . 6
3.8 Privileged Object Types . . . . . . . . . . . . . 6
3.9 Restriction on Task Names . . . . . . . . . . . . 6
3.10 Network Topology Software Interrupt . . . . . . . 6
3.11 SET HOST Command . . . . . . . . . . . . . . . . . 7
3.12 Making HOST connections to VMS . . . . . . . . . . 7
3.13 NRT connections from non-TOPS-20 systems . . . . . 7
3.13.1 Segment size increased . . . . . . . . . . . . . 7
3.13.2 Parity removed on remote terminal links . . . . 7
3.14 DECnet Network Management Event Logger . . . . . . 8
3.15 Terminal Server Diagnostic Loads . . . . . . . . . 8
3.16 Elective Ethernet End Node . . . . . . . . . . . . 8
3.17 Default Source Process Identifier . . . . . . . . 8
3.18 NMLT20's Automatic Dump and Restart . . . . . . . 9
4.0 Beware Entries for CTERM . . . . . . . . . . . . . . 9
4.1 TOPS-20's CTERM-SERVER . . . . . . . . . . . . . . 9
4.2 VMS V4.0 . . . . . . . . . . . . . . . . . . . . . 9
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-6
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
Beware File for DECnet-20 V4.0, Field Test Tape 6 Page 3
17 Jul 85
APPENDIX B EVENT MESSAGE FORMAT
Beware File for DECnet-20 V4.0, Field Test Tape 6 Page 4
New CTERM-SERVER 17 Jul 85
1.0 New CTERM-SERVER
There are CTERM changes in the FT6 CTERM host which require the new
CTERM-SERVER as well. If one uses an older version of CTERM-SERVER to
connect to the FT6 CTERM host, most prompts will be typed out twice.
2.0 RMS V3
RMS V3, which implements Distributed Record Management, will not be
ready for V6.1. RMS V3 is the basis for the Data Interchange Utility
(DIU), which is to replace NFT for intersystem file transfers.
Updated versions of NFT and FAL are included on the DECnet tape.
3.0 DECnet Features and Restrictions
3.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.
3.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.
Beware File for DECnet-20 V4.0, Field Test Tape 6 Page 5
DECnet Features and Restrictions 17 Jul 85
3.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.
The MCB which is included on Field Test Tape #5 is the same as that
included on Autopatch Tape #10 for TOPS-20 V5.1 and on V6.1's Field
Test Tape #4. Many field tests sites are running this MCB with no
problem, but two sites have found that the new MCB cycles lines
frequently. We would like to understand this problem, and thus would
appreciate hearing whether or not it works at your site. If you find
that the new MCB does not work at your site, you should be able to
back off to your old MCB with no ill effect.
3.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.
3.5 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.
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.
Beware File for DECnet-20 V4.0, Field Test Tape 6 Page 6
DECnet Features and Restrictions 17 Jul 85
;This patch is for the 6.1 MCB
[Recording initiated at Thu 11-Apr-85 16:22:09]
LINK FROM GLINDELL, TTY 314
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
$pop
[Recording terminated at Thu 11-Apr-85 16:23:02]
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.
3.6 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, Field Test Tape 6 Page 7
DECnet Features and Restrictions 17 Jul 85
These records indicate that t2 has detected an illegal disconnect
confirm message, usually from a VMS system. The VMS engineering group
intends to fix this in some 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.
3.7 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; it does not check the protocol type at all. This
is not an error.
3.8 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.
3.9 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.
3.10 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.
Beware File for DECnet-20 V4.0, Field Test Tape 6 Page 8
DECnet Features and Restrictions 17 Jul 85
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.
3.11 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).
3.12 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.
3.13 NRT connections from non-TOPS-20 systems
3.13.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.
3.13.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.
Beware File for DECnet-20 V4.0, Field Test Tape 6 Page 9
DECnet Features and Restrictions 17 Jul 85
3.14 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 presents the event logger in more detail.
3.15 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.
3.16 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.
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.
3.17 Default Source Process Identifier
Default Source Process Identifier (PID) for the DCN: device has been
changed from a unique number to a user name in order to support
VMS-style outgoing Proxy Access.
Beware File for DECnet-20 V4.0, Field Test Tape 6 Page 10
DECnet Features and Restrictions 17 Jul 85
3.18 NMLT20's Automatic Dump and Restart
NMLT20 will dump itself to logical name DMP:, and it will run a
program pointed to by RUNNML: after crashing. It will print a
message on the CTY telling the operator what files were used.
4.0 Beware Entries for CTERM
There are a number of known CTERM bugs in this field test tape.
4.1 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.2 VMS V4.0
RTPAD (SET HOST) under VMS V4.0 has the following known CTERM bugs:
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.
Beware File for DECnet-20 V4.0, Field Test Tape 6 Page 11
Beware Entries for CTERM 17 Jul 85
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.
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.)
List of all events defined in DEcnet phase IV network management
================================================================
NETWORK MANAGEMENT EVENT LOGGER Page A-2
The DECNET event logger 17 Jul 85
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
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
NETWORK MANAGEMENT EVENT LOGGER Page A-3
The DECNET event logger 17 Jul 85
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 ...
NCP> SET LOGGING FILE ...
NCP> SET LOGGING MONITOR ...
or if the same operation is desired on all sinks
NETWORK MANAGEMENT EVENT LOGGER Page A-4
The three logging sinks 17 Jul 85
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)
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
NETWORK MANAGEMENT EVENT LOGGER Page A-5
The three logging sinks 17 Jul 85
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
The latter could also have been accomplished with the sequence:
NCP> SET KNOWN LOGGING EVENT 0.0-9
NETWORK MANAGEMENT EVENT LOGGER Page A-6
Selecting what events to report 17 Jul 85
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
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
NETWORK MANAGEMENT EVENT LOGGER Page A-7
Event logger and system startup 17 Jul 85
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 a lot of
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 that 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.
If you experience a lot of "lost events" you should examine your
reports to find out what event that may be happening frequently.
NETWORK MANAGEMENT EVENT LOGGER Page A-8
Implementation details 17 Jul 85
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 17 Jul 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 17 Jul 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 flavours 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
17 Jul 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.