Trailing-Edge
-
PDP-10 Archives
-
BB-H348C-RM_1982
-
swskit-v21/documentation/event.doc
There are no other files named event.doc in the archive.
Functional Specification For
DECnet EVENT LOGGING
ABSTRACT
Event logging will be provided to allow preservation of
valuable information regarding system state changes
occasioned by hardware malfunctions, alterations of network
topology or system configuration, and other events. Logging
will be effected using the NICE protocol. Inputs to NICE
will originate from newly developed reporting software
integrated with the appropriate modules.
DECNET EVENT LOGGING Page 2
PRODUCT OVERVIEW 01 Apr 82
1.0 PRODUCT OVERVIEW
1.1 Product Abstract
This document describes the data flow and formats employed
in the DECnet-20 implementation of event logging. The
design provides for a flexible and open-ended usage,
allowing for future growth. The event types to be recorded
are:
o ASCII Information: Self-explanatory textual
information.
o Hardware Error: Indication of a hardware error.
o Software Error: Indication of a software error.
o Topology Change: Indication of a change in the
makeup of the network containing the source and
target (such as a node being added or deleted, or a
line going down).
Logging will be effected using the NICE protocol. Inputs to
NICE will originate from newly developed reporting software
integrated with appropriate modules (see 3.0).
1.2 Markets
This product is an integral part of all DECnet-20
installations. The logging capability is designed to
enhance the RAMP (Reliability, Availability,
Maintainability, and Performance) features of the system.
1.3 Competitive Analysis
1.4 Product Audience
Addition of the event logging capability is directed toward
three groups: field service / software support, system
managers, and system operators.
2.0 PRODUCT GOALS
DECNET EVENT LOGGING Page 3
PRODUCT GOALS 01 Apr 82
2.1 Performance
Inclusion of the event logging features should have minimal,
or no, effect on system performance, particularly when
loggable events are not occurring. However, as logging
activity increases, some system degradation will occur:
both logging operations and recovery/processing activities
contribute to the degradation.
2.2 Support Objectives
This functionality is part of the DECnet-20 software, and
thus, will be supported as part of that product. The first
release will record information concerning several key
system components. Note that definition of logged
components is entirely open-ended: new items or categories
can be added as needed.
2.3 Environments
The event logging functionality is to be inherent in all
DECnet-20 systems.
2.4 Reliability Goals
Event logging should have no adverse effects on system
reliability, and should enhance system availability by
reducing the time for fault location and repair.
2.5 Non-goals
A report generator to utilize/manipulate the logged
information is not part of this specification.
As per the statement in "Support Objectives" above, this
specification makes no attempt at providing an all inclusive
list of events to be logged, rather it provides the
framework for orderly evolution. Considerations such as
full utilization of modem control information, or
application of data supplied by network management devices
are not pursued in this document. However, as definitions
in those areas become clear, this product can be enhanced
appropriately.
DECNET EVENT LOGGING Page 4
FUNCTIONAL DEFINITION 01 Apr 82
3.0 FUNCTIONAL DEFINITION
Within the MCB, logging will be instigated by transmission
of a communications control block (CCB) to the Network
Services Protocol (NSP) process. The transmission occurs
via the MCB system facility "$LLCRS", a routine which allows
asynchronous communication between Logical Link Control
(LLC) processes. NSP will subsequently pass the information
to NICE via the mailbox queueing mechanism. The NICE task
will then format the data into a message as specified below,
and finally send that message to a NICE task on the
appropriate host for logging. The host node will have been
previously specified via the NICE "Set Parameter" function.
Internal message formats for transmissions from event
detectors to NSP are documented in Appendix D. Since NSP
performs no processing on the data, Appendix D thus
constitutes the input definition for NICE.
3.1 Functional Description
The following subsections contain descriptions of the
defined event types and the formats to be used. The
following diagram is presented here to illustrate how the
events defined in this document relate to the Log Data Event
of [Ref.1].
Log-Data-Message::
+------+-----+------+------+-----+-------+----------+
! FUNC ! OPT ! NODE ! COMP ! SEQ ! EVENT ! LOG-DATA !
+------+-----+------+------+-----+-------+----------+
The formatting notation used in the following description,
and throughout this document, is described in Appendix A.
FUNC (1):B = Function code = 1.
OPT (1):B = Option code. For this
implementation, the option field
will always use the code of "1",
maintenance log.
NODE (I-6):A = Original source node of the
logging message.
COMP (I-16):A = Name of component event is from.
SEQ (1):B = Sequence number assigned by the
transmitter, for detection of
missing logged events.
DECNET EVENT LOGGING Page 5
FUNCTIONAL DEFINITION 01 Apr 82
EVENT (2):B = Event code identifying the event
being logged. These codes are
defined in this document.
LOG-DATA (*):B = Log data, with content according
to event.
This document is primarily concerned with the final field
"LOG-DATA"; the other data fields are defined in [Ref.1].
Within LOG-DATA, each data field is introduced by a one-byte
sentinel, the Data Type code. Thus, only essential data
fields need be included in a given message. Further,
ordering of data items within LOG-DATA is not specified. A
suggested format for each event type is given below.
3.1.1 ASCII Information -
EVENT TYPE: (1)
DATA FIELDS:
DEV-ID (I-5):B = [Data Type 5] Device
Identification in the standard
NICE format (Appx. B).
TIME (EX-3):B = [Data Type 2] Event time of day.
DATE (4):B = [Data Type 3] Date of the event.
UPTIME (EX-4):B = [Data Type 4] Number of seconds of
source uptime.
TEXT (I-255):A = [Data Type 14] Self-defining ASCII
information.
3.1.2 ASCII Information (Extended) -
EVENT TYPE: (2)
DATA FIELDS:
The Extended ASCII type has been provided to allow
logging of ASCII messages of arbitrary length.
Message formatting is identical to that for the normal
ASCII transmission described above, but a message may
comprise one or more transmissions. The
end-of-message is signaled by a transmission with a
zero length TEXT field.
DECNET EVENT LOGGING Page 6
FUNCTIONAL DEFINITION 01 Apr 82
3.1.3 Hardware Error -
EVENT TYPE: (3)
DATA FIELDS:
DEV-ID (I-5):B = [Data Type 5] Device
Identification in the standard
NICE format (Appx. B).
REGISTERS (I-255):B = [Data Type 1] Hardware device
registers. The register format is
device dependent, as described in
Appendix C.
TIME (EX-3):B = [Data Type 2] Time of day device
error occurred.
DATE (4):B = [Data Type 3] Date of the device
error.
UPTIME (EX-4):B = [Data Type 4] System uptime when
device error occurred.
REASON (EX-2):B = [Data Type 6] Device error type
(Appx. C).
RECOVERY (I-255):B = [Data Type 7] Information to be
used in any recovery procedure the
event-log recipient might
initiate. [To be specified]
OS-ID = [Data Type 8] Operating System
identification (Appx. B).
3.1.4 Software Error - [Unsupported for Release 4.0].
EVENT TYPE: (4)
DATA FIELDS:
[To be specified]
3.1.5 Topology Change - [Unsupported for Release 4.0].
EVENT TYPE: (5)
DATA FIELDS:
NODE-ID (I-6):A = [Data Type 9] Node identification.
DEV-ID (I-5):B = [Data Type 5] Line identification
(Appx. B).
DECNET EVENT LOGGING Page 7
FUNCTIONAL DEFINITION 01 Apr 82
TIME (EX-3):B = [Data Type 2] Time of day topology
change occurred.
DATE (4):B = [Data Type 3] Date of the topology
change.
REASON (EX-2):B = [Data Type 6] Code defining the
reason for the topology change.
[To be specified]
3.2 Restrictions
4.0 COMPATIBILITY
The capabilities described in this specification establish a
base for event logging in all DECnet implementations. Thus,
the event logging function must be format compatible across
many product lines. This document addresses both the
general formatting and the specific operational
functionality in DECnet-20.
5.0 EXTERNAL INTERACTIONS AND IMPACT
6.0 R A M P
Implementations of the features described in this
specification will ease the system service burden, because
collected information will be available for use both in
preventative and diagnostic maintenance. For example,
detection of malfunction trends may well portend
catastrophic failures. Similarly, when failures do occur,
availability of the system operational history will speed
determination of the offending module or subsystem.
7.0 PACKAGING AND SYSTEM GENERATION
8.0 DOCUMENTATION
9.0 REFERENCES
References are denoted in the text by enclosing the
reference number in square brackets, i. e., [Ref.n].
1. Network Information and Control Executor Process -
NICE, Version 1.0, Bob Stewart, 28 March 1977.
DECNET EVENT LOGGING Page 8
REFERENCES 01 Apr 82
2. Functional Specification for Network Event/Error
Logging Under TOPS10 and TOPS20, MEG-0103, Ray
Drueke, 29 March 1978.
3. Data Access Protocol (DAP) Functional
Specification, Version 5.0, 21 September, 1978.
APPENDIX A
MESSAGE FORMATTING NOTATION
The following notation description is an extraction from
[Ref.1]. The notation is used in all message format
descriptions in this document, and appears as follows:
Field (Length):Coding = Description of field.
Field = The name of the field being described.
Length = The length of the field as:
o A number specifying the number of eight-bit bytes,
or an asterisk "*", implying all remaining bytes in
the message.
o A number followed by a "B", meaning the number of
bits.
o The letters "EX-n", meaning an extensible field
with a length of up to "n" eight-bit bytes. If "n"
is not specified, the length is limited only by the
maximum NSP message length.
Extensible fields are of variable length (comprised
of an integral number of eight-bit bytes), with the
high-order bit of each byte signalling whether the
next byte is part of the same field. Extensible
fields can be ASCII, binary, or bit map. If the
field is ASCII, then it merely consists of the
string of seven-bit ASCII characters. If the field
is binary, then the successive seven-bits of each
byte are concatenated to form the intended binary
quantity. In the case of bit maps, the seven bits
from each byte are used independently as
information bits. Thus, in both binary and bit map
usage, the information is relevant after removing
MESSAGE FORMATTING NOTATION Page A-2
01 Apr 82
the extension bits and compressing the bytes.
o The letters "I-n" defining an image field with a
maximum length of "n" eight-bit bytes. The image
field is preceeded by a one-byte length field.
This length field contains a count of the number of
bytes in the image field, exclusive of the length
field itself. Thus image fields are variable in
length, and may even be null (length of zero). All
eight bits of each byte is available for conveyance
of information.
Coding = The representation type used:
o A = ASCII (seven bit)
o B = Binary
o BM = Bit Map - each bit or group of bits has
independent meaning.
o C = Constant
o null = Interpretation is data dependent.
The following list enumerates several general ground rules
for interpretation and use of the formatting notations.
o If the length and coding are unspecified, then
"Field" represents a composite field, with a number
of subfields to be specified in the specific
description.
o All numeric values in this document are shown in
decimal representation, unless otherwise specified.
o Any bit, group of bits, or field which is labeled
as "reserved" shall always be coded as zero, unless
otherwise specified.
o The least significant byte of a field is always
presented first to the physical link protocol. In
an ASCII field, the logically left-most character
in the string is in the least significant byte.
o Bytes are considered as consisting of eight bits,
with the low-order bit being bit zero, and the
high-order bit being bit seven.
APPENDIX B
EVENT AND DATA FIELD CODES
B.1 EVENT CODES
Code Description
0 Illegal.
1 Self-descriptive messages of ASCII text.
2 Self-descriptive extended messages of ASCII text.
3 Hardware error.
4 Software error.
5 Topology Change.
EVENT AND DATA FIELD CODES Page B-2
DATA TYPE CODES 01 Apr 82
B.2 DATA TYPE CODES
Code Name & Format Description
0 Illegal.
1 REGISTERS (I-255) = This field conveys the device
register contents at the time of
error occurrence.
2 TIME (EX-3):B = A field containing the time of day
of event occurrence, expressed as
seconds since midnight. While it
is readily acknowledged that there
are problems associated with time
synchronization across network
nodes, it is felt that this timer
will at least reflect the
node-relative time of event
occurrence. Further, with some
effort, a report generator program
can relate this timer value to a
network-wide scale. The main
problem then remaining is
elimination of timer errors caused
by imprecise local settings.
3 DATE (4):B = A field containing the date of
event occurrence, formatted as
follows:
0: Day of Month
1: Month
2-3: Year
4 UPTIME (EX-4):B = The number of seconds of system
uptime when the event occurred.
5 DEV-ID (I-5):B = The device identification. This
structured field is parsed
according to the format
designation in the first byte.
Note that the definition stated
here constitutes an extension of
the definition in [Ref.1].
EVENT AND DATA FIELD CODES Page B-3
DATA TYPE CODES 01 Apr 82
0: Format code byte
Format 0: Not used.
Format 1: Standard Line ID
1: Device ID
2: Controller #
3: Line #
4: Station #
Format 2: Not used
Format 3: General Devices
1: Device ID
2: Device model
3: Controller #
4: Unit #
Refer to Appendix C for
definitions of line and device
identification codes.
6 REASON (EX-2):B = A code defining why the event
occurred. Specific reason codes
are itemized within Event Type
definitions.
7 RECOVERY (I-255):B = The recovery actions to be
attempted for a given event. [To
be specified]
8 OS-ID = The Operating System
identification [Ref.3].
OS-TYPE (1):B = OS type code, as per the following
table.
OS Types:
0 Illegal
1 RT-11
2 RSTS/E
3 RSX-11S
4 RSX-11M
5 RSX-11D
6 IAS
7 VAX/VMS
8 TOPS-20
9 TOPS-10
10 RTS-8
11 OS-8
12 RSX-11M+
EVENT AND DATA FIELD CODES Page B-4
DATA TYPE CODES 01 Apr 82
13 DN60
14 DECnet Intercept
15 DN8x
16 DN92
17 RSX-20F
18 DECnet Non-intercept
19-191 Reserved to DEC
192-255 Reserved to customer
OS-NAME (I-255):A = The ASCII OS identification.
9 NODE-ID (I-6):A = Node identification.
10 MCODE (2):B = The device microcode descriptor,
formatted as follows:
0: Microcode type
1: Version number
Defined microcode types consist
of:
Type Description
0 Illegal
1 COMM/IOP
2 DN60
3 KMC/DZ
4 KMC/DUP
5 DMC
11 L-PROTOCOL (EX-1):B = Line protocol designator.
0 Illegal
1 Unknown
2 None
3 DDCMP
4 SDLC
5 BISYNC
6 NSP
7 HDLC
12 T-PROTOCOL (EX-1):B = Transmission protocol
designator. Note that some bit
combinations constitute impossible
or illegal specifications.
Bit Off / On
0 Point-to-point / Multi-point
1 1-channel / 2-channel
EVENT AND DATA FIELD CODES Page B-5
DATA TYPE CODES 01 Apr 82
2 2-wire / 4-wire
3 Switched / Continuous
4 Half-duplex / Full-duplex
5 Reserved
6 Reserved
13 THRESHOLD (2):B = The threshold value relevant to
the event being reported.
14 TEXT (I-255):A = Self-defining ASCII information.
APPENDIX C
DEVICE IDENTIFIERS AND REGISTER FORMATS
For each reportable device type, control and status register
contents will be incorporated in event log messages. Note
that although the descriptions specify sequences of 16-bit
words, transmission is by bytes; the low-order byte is
transmitted first. Relative address offsets are used to
indicate successive words of the device registers, with
register names supplied parenthetically. Register contents
are not detailed herein - consult the appropriate source
documents.
Each device entry below lists the specific events detected
for logging (Reason Code), and specifies the ordered set of
device registers. Logging is currently specified only for
those devices for which Event Reason Codes are enumerated.
Additionally, the software DDCMP code (DCP) reports on
behalf of devices for which it is providing protocol support
(see C.1.1). No register values are logged in these
instances, however, because event detection/reporting occurs
asynchronously with actual device operation, and register
contents are not available.
The reason codes are defined below. Note that code zero is
an illegal entry.
1. Unclassified (undefined) reason code.
2. Non-existent memory.
3. Lost interrupt enable.
4. Spurious interrupt.
5. Unexpected data set carrier transition.
6. Receiver timeout.
7. Power failure (soft).
8. Power recovery.
9. Retransmission threshold exceeded.
10. Receiver overrun.
11. Lost data - message too long for buffer.
12. Maintenance message received during normal
operation.
DEVICE IDENTIFIERS AND REGISTER FORMATS Page C-2
01 Apr 82
13. DDCMP start received during normal operation.
14. DDCMP header format error.
15. SDLC operation aborted.
16. Parity error on transmission bus.
17. Parity error in memory.
18. Parity error in transmitted character.
19. CRC error.
20. Framing error.
21. Procedure error.
22. Transfer error.
23. Transmitter timeout.
24. Select error.
25. Receive error threshold exceeded.
26. NAK threshold exceeded.
DEVICE IDENTIFIERS AND REGISTER FORMATS Page C-3
COMMUNICATIONS DEVICES 01 Apr 82
C.1 COMMUNICATIONS DEVICES
The following subsections (arranged alphabetically by device
name), describe the registers and other information conveyed
for each device. Although not a device, the DDCMP process
(DCP) is included here because it acts on behalf of some
devices which are utilizing the protocol. For reference
convenience, the devices are listed in numerical order
below. Note that communications devices are assigned only
even-numbered ID codes.
The Release 4.0 implementation of error/event logging will
provide information logging for the devices detailed in the
following subsections. Devices named, but not detailed, are
excluded.
ID Device ID Device
0 DP11 2 DU11
4 DL11 6 DQ11
8 DA11 10 DUP11
12 DMC11 14 DN11
16 DLV11 18 DNP11
20 DTE20 22 DV11
24 DZ11 26 Unassigned
28 KMC/DUP11 30 KMC/DZ11
32 KL8J
C.1.1 DA11
DEVICE ID: (8)
REGISTERS:
EVENTS:
C.1.2 DCP
DEVICE ID: (none)
REGISTERS:
EVENTS:
09 Retransmission threshold exceeded.
12 Maintenance message received during normal
operation.
13 Start received during normal operation.
24 Station select error.
DEVICE IDENTIFIERS AND REGISTER FORMATS Page C-4
COMMUNICATIONS DEVICES 01 Apr 82
25 Receive error threshold exceeded.
26 NAK threshold exceeded.
C.1.3 DLV11
DEVICE ID: (16)
REGISTERS:
EVENTS:
C.1.4 DL11
DEVICE ID: (4)
REGISTERS:
EVENTS:
C.1.5 DMC11
DEVICE ID: (12)
REGISTERS:
0 Input transfer and maintenance CSR (SEL0).
2 Output transfer CSR (SEL2).
4 First half of data port (SEL4).
6 Second half of data port (SEL6).
EVENTS:
02 Non-existent memory. UNIBUS timeout has occurred.
05 Disconnect. Modem on/off transition detected.
06 Receiver timeout. No response from sender.
09 Retransmission threshold exceeded.
10 Overrun. No buffer available for incoming data.
11 Lost data. Message was too long for buffer.
12 Maintenance message received during normal
operation.
13 DDCMP start received during normal operation.
C.1.6 DN11
DEVICE ID: (14)
REGISTERS:
DEVICE IDENTIFIERS AND REGISTER FORMATS Page C-5
COMMUNICATIONS DEVICES 01 Apr 82
EVENTS:
C.1.7 DNP11
DEVICE ID: (18)
REGISTERS:
EVENTS:
C.1.8 DP11
DEVICE ID: (0)
REGISTERS:
EVENTS:
C.1.9 DQ11
DEVICE ID: (6)
REGISTERS:
EVENTS:
C.1.10 DTE20
DEVICE ID: (26)
REGISTERS:
0 Delay counter (DLYCNT), plus UNIBUS address
extension bits.
2 Deposit/examine word #3 (DEXWD3).
4 Deposit/examine word #2 (DEXWD2).
6 Deposit/examine word #1 (DEXWD1).
8 KL10 memory address word #1 (TENAD1).
10 KL10 memory address word #2 (TENAD2).
12 To -10 byte count (TO10BC).
14 To -11 byte count (TO11BC).
16 To -10 address (TO10AD).
18 To -11 address (TO11AD).
20 To -10 data word (TO10DT).
22 To -11 data word (TO11DT).
24 Diagnostic/control register #1 (DIAG1).
26 Diagnostic/control register #2 (DIAG2).
DEVICE IDENTIFIERS AND REGISTER FORMATS Page C-6
COMMUNICATIONS DEVICES 01 Apr 82
28 Control/status register (CSTAT).
30 Diagnostic/control register #3 (DIAG3).
EVENTS:
01 Protocol halted. The "valid examine" not in
effect.
04 DTE20 consistency check. Interrupt for completion
done, but data count has not expired, or final
transfer addresses don't match.
13 Start received while on line.
16 KL10 is down.
21 Protocol consistency check.
22 Data transfer error.
C.1.11 DUP11
DEVICE ID: (10)
REGISTERS:
0 Receiver status register (RxCSR).
2 Receiver data buffer register (RxDBUF), or
parameter status register (PARCSR).
4 Transmitter status register (TxCSR).
6 Transmitter data buffer register (TxDBUF).
EVENTS:
06 Receiver timeout.
10 Receiver data overrun.
19 CRC error.
C.1.12 DU11
DEVICE ID: (2)
REGISTERS:
EVENTS:
C.1.13 DV11
DEVICE ID: (22)
REGISTERS:
EVENTS:
DEVICE IDENTIFIERS AND REGISTER FORMATS Page C-7
COMMUNICATIONS DEVICES 01 Apr 82
C.1.14 DZ11
DEVICE ID: (24)
REGISTERS:
0 Control and status register (CSR).
2 Receive data buffer register (RBUF), or line
parameter register (LPR).
4 Transmitter control and data terminal ready
registers (TCR and DTR).
6 Ring and carrier registers (RING and CAR), or
transmitter buffer and break registers (TBUF and
BRK).
EVENTS:
06 Receiver timeout.
10 Receiver data overrun.
18 Character parity error.
20 Framing error.
C.1.15 KL8J
DEVICE ID: (32)
REGISTERS:
EVENTS:
C.1.16 KMC/DUP11
DEVICE ID: (28)
REGISTERS:
KMC11
0 Control register (SEL0).
2 Control register (SEL2).
4 First half of data port (SEL4).
6 Second half of data port (SEL6).
DUP11
0 Receiver status register (RxCSR).
2 Receiver data buffer register (RxDBUF), or
parameter status register (PARCSR).
4 Transmitter status register (TxCSR).
6 Transmitter data buffer register (TxDBUF).
EVENTS:
05 Data set ready transition.
06 Receiver timeout.
10 Receiver data overrun.
14 DDCMP header format error.
DEVICE IDENTIFIERS AND REGISTER FORMATS Page C-8
COMMUNICATIONS DEVICES 01 Apr 82
15 SDLC operation aborted.
19 CRC error.
23 Transmitter timeout.
C.1.17 KMC/DZ11
DEVICE ID: (30)
REGISTERS:
KMC11
0 Control register (SEL0).
2 Control register (SEL2).
4 First half of data port (SEL4).
6 Second half of data port (SEL6).
DZ11
0 Control and status register (CSR).
2 Receive data buffer register (RBUF), or line
parameter register (LPR). This value will be
reported as a minus one (-1) because of the
read-once" nature of the register. By the time
error logging is initiated, the register has
already been processed by the KMC, and the input
value is no longer available.
4 Transmitter control and data terminal ready
registers (TCR and DTR).
6 Ring and carrier registers (RING and CAR), or
transmitter buffer and break registers (TBUF and
BRK).
EVENTS:
06 Receiver timeout.
10 Receiver data overrun.
18 Character parity error.
20 Framing error.
DEVICE IDENTIFIERS AND REGISTER FORMATS Page C-9
I/O DEVICES 01 Apr 82
C.2 I/O DEVICES
The following subsections (arranged alphabetically by device
name), describe the registers and other information conveyed
for each device. For reference convenience, the devices are
listed in numerical order below. Note that I/O devices are
assigned only odd-numbered ID codes.
\The following codes are being proposed for generically
specifying I/O devices. Finer device resolution will be
provided in a sub-code, i.e., model #. Refer to DEV-ID in
Appendix B.\
ID Device ID Device
1 Memory 3 Disk, removable
5 Disk, fixed 7 Disk, floppy
9 Line Printer 11 Card Reader
13 Magnetic Tape 15 Cassette
17 Paper Tape 19 Sensor Device
C.2.1 Card Reader
DEVICE ID: (11)
MODEL:
REGISTERS:
EVENTS:
C.2.2 Cassette
DEVICE ID: (15)
MODEL:
REGISTERS:
EVENTS:
C.2.3 Disk, Fixed
DEVICE ID: (5)
MODEL:
DEVICE IDENTIFIERS AND REGISTER FORMATS Page C-10
I/O DEVICES 01 Apr 82
REGISTERS:
EVENTS:
C.2.4 Disk, Floppy
DEVICE ID: (7)
MODEL:
REGISTERS:
EVENTS:
C.2.5 Disk, Removable
DEVICE ID: (3)
MODEL:
REGISTERS:
EVENTS:
C.2.6 Line Printer
DEVICE ID: (9)
MODEL:
REGISTERS:
EVENTS:
C.2.7 Magnetic Tape
DEVICE ID: (13)
MODEL:
REGISTERS:
EVENTS:
DEVICE IDENTIFIERS AND REGISTER FORMATS Page C-11
I/O DEVICES 01 Apr 82
C.2.8 Memory
DEVICE ID: (1)
MODEL:
REGISTERS:
EVENTS:
C.2.9 Paper Tape
DEVICE ID: (17)
MODEL:
REGISTERS:
EVENTS:
C.2.10 Sensor Device
DEVICE ID: (19)
MODEL:
REGISTERS:
EVENTS:
APPENDIX D
INTERNAL EVENT LOG MESSAGE FORMATS
The internal event logging format varies according to the
type of event being handled. The types directly correspond
to those identified in 3.1. All information for logging
will be conveyed in the data buffer attached to the
communications control block (CCB).
D.1 ASCII INFORMATION
[To be specified].
D.2 HARDWARE ERROR
EVENT-TYPE (2):B = The hardware error event code
(=3).
TIMESTAMP (4):B = Time of event detection. The byte
values are as follows:
0: Day of month (1-31)
1: Hour of day (0-23)
2: Minute of hour (0-59)
3: Second of minute (0-59)
PROC-NAME (2):B = Name of originating process, in
radix-50.
REASON (2):B = Reason for the event.
DEVICE-ID (1):B = Device identification, as per
Appendix C.
INTERNAL EVENT LOG MESSAGE FORMATS Page D-2
HARDWARE ERROR 01 Apr 82
CONTROLLER (1):B = Device controller number.
UNIT (1):B = Unit number within a controller.
A value of 255 (-1) indicates
there is no unit designation, and
implicitly indicates there is no
station designation.
STATION (1):B = Station number on a unit. A value
of 255 (-1) indicates there is no
station designation.
The remainder of the information buffer will contain
selectable information, as needed. Thus, the message might
appear as follows:
+--------++------+-----+---------+------+-----+---------+
! HEADER !! CODE ! LNG ! DATA ! CODE ! LNG ! DATA !
+--------++------+-----+---------+------+-----+---------+
"HEADER" comprises the data items defined above. "CODE" is
the one-byte type code defined in Appendix B, and "LNG" is
the length of "DATA", in bytes. Data supplied via this
mechanism will typically include a snapshot of the device
registers, and possibly an event reporting threshold. Other
information may be supplied, as appropriate to event
requirements.
D.3 SOFTWARE ERROR
[To be specified].
D.4 TOPOLOGY CHANGE
[To be specified].