Trailing-Edge
-
PDP-10 Archives
-
k20v7b
-
decnet/event-logger.mem
There are 3 other files named event-logger.mem in the archive. Click here to see a list.
1.0 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
================================================================
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
Page 2
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
5.7 Circuit Selection address error
5.8 Circuit Streaming tributary
5.9 Circuit Local buffer too smAny
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
Page 3
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.
2.0 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
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
Page 4
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.
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
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
Page 5
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.
3.0 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
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.
Page 6
4.0 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
5.0 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.
Page 7
6.0 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.
7.0 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.
8.0 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
Page 8
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.
9.0 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
10.0 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.
Page 9
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.
11.0 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::
Page 10
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 A
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 A-2
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.