Digital PDFs

DEC-11-OMELA-A-D

April 1976

55 pages

Original

1.9MB

Document:	RSX-11M Error Logging Reference Manual
Order Number:	DEC-11-OMELA-A-D
Revision:	0
Pages:	55
Original Filename:	http://bitsavers.org/pdf/dec/pdp11/rsx11m_s/RSX11M_V2/DEC-11-OMELA-A-D_eLog_197604.pdf

OCR Text

RSX-11M
Error Logging
Reference Manual
Order No. DEC-11-0MELA-A-D

RSX-llM Version 2

digital equipment corporation · maynard, massachusetts

First Printing, April 1976
The information in this document is subject to change without notice
and should not be construed as a commitment by Digital Equipment
Corporation. Digital Equipment Corporation assumes no responsibility
for any errors that may appear in this document.
The software described in this document is furnished under a license
and may be used or copied only in accordance with the terms of such
license.
Digital Equipment Corporation assumes no responsibility for the use or
reliability of its software on equipment that is not supplied by
DIGITAL.

@ 1976 by Digital Equipment Corporation

The postage prepaid READER'S COMMENTS form on the last page of this
document requests the user's critical evaluation to assist us in preparing future documentation.

The following are trademarks of Digital Equipment Corporation:

DIGITAL
DEC
PDP
DECUS
UNIBUS
COMPUTER LABS
COMT EX

DDT
DECCOMM

DECsystem-lo
DECtape
DIBOL
EDU SYSTEM
FLIP CHIP
FOCAL
INDAC
LAB-8
DECsystem-20

MASSBUS
OMNIBUS
OS/8
PHA
RSTS
RSX
TYPESET-8
TYPESET-10
TYPESET-11

PREFACE

0.1 MANUAL OBJECTIVES AND READER ASSUMPTIONS

The RSX-llM Error Logging Reference Manual
contains
all
the
information needed to operate the error logging subsystem. Its main
purpose is to enable the user to produce error logging reports, which
allow the user to monitor the hardware reliability of an RSX-llM
system and provide DIGITAL field service engineers with a convenient
history of system performance.
This manual assumes a familiarity with the following documents:
The RSX-llM Operator's Procedures Manual
The RSX-llM Utilities Procedures Manual
The RSX-llM System Generation Manual

0.2 STRUCTURE OF THE DOCUMENT

Chapter l describes the purposes and functions of error logging.
Chapter 2 describes how the Executive logging features and the
logging tasks interface to produce the final: readable reports.
Chapter 3 describes the procedures for
tasks and lists associated messages.

operating

the

error

error
logging

Chapter 4 describes the error log reports generated by the subsystem.
Chapter 5 describes the procedures for generating the error logging
subsystem from system generation through assembly, task building and
task installation.
Appendix A explains how to modify the analyzer task SYE at task build.

0.3 ASSOCIATED DOCUMENTS

The
RSX-llM/RSX-llS
Documentation
Directory,
Order
No.
DEC-11-0MUGA-B-D, defines the intended readership of each manual in
the RSX-llM set and provides a brief synopsis of each manual's
contents.
References are made in the error logging manual to several
other RSX-llM documents; readers should consult the directory for
information about these documents.

CHAPTER 1
INTRODUCTION

1.1

THE PURPOSES OF ERROR LOGGING

The RSX-llM error logging subsystem monitors the hardware reliability
of an RSX-llM system; it continually detects and records information
about every disk or DECtape error as it occurs, regardless of whether
or not it is recoverable.
Then at user-determined intervals, an
analysis task can be run to generate individual error and/or summary
reports on some or all of these errors. Without the error logging
facility, the Executive automatically retries recoverable errors;
after a successful recovery, however, the user is unaware that the
error ever occurred.
Error logging may be implemented on any RSX-llM system that is 24K
larger.

Error logging reports are useful for efficient maintenance of the
hardware on which the RSX-llM system runs. Problems such as line
noise, static discharges, or inherently error prone media, for
instance, can cause recoverable errors on systems that are otherwise
functioning normally. By studying reports generated by the analysis
task, the user can learn to distinguish these kinds of errors from
those that might be symptoms of an impending device failure.
On the
other
hand, some recoverable errors that are insignificant in
themselves might be related to other, more serious errors, the effects
of which are not immediately apparent. Information contained in the
reports about each error and about the status of the system when the
error occurred may alert the system manager to a previously unforeseen
hardware problem.
If the error reports seem to indicate an impending failure, the system
manager can contact a DIGITAL field service engineer who will use the
reports to help in diagnosing the problem. Sometimes a device fails
so quickly that error logging is unable to predict the failure in time
to prevent it. In this case, the field service engineer can determine
the cause more quickly if a report is available which describes the
errors that may have occurred immediately prior to the failure.

1.2

THE FUNCTIONS OF ERROR LOGGING

Without the error logging facility installed in the system, the
RSX-llM Executive detects each hardware error, then either ignores it
if it causes no immediate problem or, when appropriate, retries the
function that caused the error. The user normally has no means of
knowing that such an error occurred. However, when the error logging
facility has been generated, the system detects the errors and then
performs three further operations in order to produce an error report.
In summary, error logging:
1-1

INTRODUCTION
1.

Detects a hardware error as it occurs

Gathers information about the error

Stores the information in a file

Analyzes the information to produce an error report

Control of the facility is shared between routines in the Executive
and specific error logging tasks. These routines and tasks interface
with each other to carry out the four operations described above. The
error logging tasks are ERRLOG, PSE, SYE and ERF. Chapter 2 describes
how the Executive routines and error logging tasks interact to produce
the final reports.
Chapter 3 tells the user how to run these tasks
and lists the error messages associated with each of them.
The task
SYE, called the Error Log Analyzer, generates the error logging
reports according to user-specified switches.
These reports are
described in detail in Chapter 4.

1.2.1

Error Detection

Error logging routines in the Executive monitor three types of errors:
1.

Interrupts through unused vectors

Device errors

Interrupt timeouts

If the error logging facility has been generated into the Executive
and the error logging tasks have been installed, all unused vectors
are filled with pointers to error logging routines.
Therefore, when
an unusually noisy electrical environment or a static discharge causes
an interrupt to occur to an unused vector, or a valid interrupt to be
corrupted to the wrong address, Executive routines can determine and
record the incorrectly used vector.
Device errors are conditions that cause a device controller to
interrupt with its error bit set. When a device error occurs and
error logging is active, Executive routines record the contents of the
device registers, which indicate the state of the device and its
controller. In addition, these routines record information about the
actual I/O request to aid in the interpretation of the device error.
An interrupt timeout occurs when a device on which a transfer was
initiated fails to interrupt within a specified amount of time.
Interrupt timeouts are detected by software timers started when the
transfer is initiated.
The system records the same information for
interrupt timeouts as it does for device errors.

1.2.2

Information Gathered

The error information gathered by the Executive routines (the state of
the registers when a device error occurs, for example) provides a
"snapshot" of the relevant parts of the system at the time of the
error.
In addition to all the system information, error routines
identify the type of error and the associated device
(for device
errors and interrupt timeouts), record the time the error occurred and
assign a sequence ~umber to the error.

1-2

INTRODUCTION
1.2.3

The Error Log File

The first two operations, error detection and the collection of error
information, are continual processes. When a certain amount of error
information has been gathered, the system calls the error logging task
ERRLOG to copy the information to a permanent error log file. The
data may be copied to a file on the system disk or to a file on a
removable disk or DECtape.

1.2.4

Analysis and Report Generation

When it is convenient or necessary to generate an error log report,
the user first runs the pre-analyzer task PSE to make a preliminary
analysis of the raw data contained in one or more error log files.
The PSE output file becomes input to SYE, the task that actually
generates the finished error logging report.
SYE is capable of generating a wide variety of individual error and/or
summary reports.
Among many other options, the user may specify a
report that covers a certain time period, a certain device or group of
devices, or perhaps a certain type of error. The user may also
request a report that contains only information on individual errors,
one that contains only summary information, or one that contains both
kinds of statistics. See Chapter 4 for a detailed description of the
error reports that SYE can generate.
Because the error log files may be written to a removable volume, the
user can generate the reports either on site or at any other RSX-llM
installation that supports the error logging facility.

1-3

CHAPTER 2
HOW ERROR LOGGING WORKS

2.1

EXBCUTIVE FEATURES

The RSX-llM Executive is responsible for
•

Detecting errors,

•

Gathering volatile data that reflects, as
closely
as
possible, the status of the system at the time of each error.

•

Controlling the amount of
error logging.

system

dynamic

memory

used

for

A set of common error routines performs these functions for all three
types of detected errors (undefined interrupts, device errors and
interrupt timeouts).
The routines use system information made available by the Executive.
~or. example~
the .Executive ~aintains a~ I/O Active Bitmap that
indicates which devices are active at any given moment. When an error
occurs, an Executive routine notes the contents of the bitmap for
subsequent analysis. The bitmap could show that the error was related
to activity on some other device.
Also, if the relevant system
generation question was answered affirmatively (see section 5.2), all
unused vectors are filled with pointers to the error routines.
Therefore, if a device improperly interrupts through an unused vector,
an error routine is able to record the address of the vector.
The common error routines are called every time an error occurs.
then perform the following three error logging functions:

They

One routine allocates memory for error logging activity.

Another gathers relevant error data and formats the raw error
messages.

The last routine queues the formatted
preparation for logging by ERRLOG.

Figure 2-1 is a flow chart diagram of the Executive
described in this section.

2-1

error

messages

routine

activity

HOW ERROR LOGGING WORKS
EXECUTIVE ERROR ROUTINES

ERROR
OCCURS

ADD 1 TO
ERROR
COUNT
MEMORY
ALLOCATION
ROUTINE

EXIT TO
CALLER
(ERROR NOT
LOGGED)

OTHER SYSTEM
AND ERROR
DATA

DEVICE
REGISTERS

1/0 ACTIVE
BITMAP
FORMATTING
ROUTINE
RAW ERROR
MESSAGE
QUEUING
ROUTINE ~-----------l

QUEUE FOR
LOGGING BY
TIME INTERVAL
(5 SECONDS)

YES

TASK
ERR LOG

ERR.TMP

Figure 2-1

Executive Error Routines

2-2

LOG
IMMEDIATELY

HOW ERROR LOGGING WORKS
2.1.1

Memory Allocation Routine

lhe memory allocation routine enforces a limit on the amount of system
dynamic memory that can be used to queue error information. The task
ERRLOG has usually recorded the raw information before this limit is
reached.
But if an unusual situation prevents ERRLOG from accessing
the queued error information, which then fills up available space, the
Executive starts to count the errors without logging them. When the
space is again available, the Executive resumes queuing the raw error
data.

2.1.2

Error Message Formatting Routines

when an error occurs, the formatting routine for that type of error
creates a raw error message containing the following information:

2.1.3

•

The error's sequence number

•

The date and time it occurred

•

A code that classifies the error

•

Any additional information needed to describe the error

Error Message Queuing Routine

The queuing routine provides the link between Executive error logging
activity and the task ERRLOG. After a raw message has been formatted,
the routine enters it in a queue, which ERRLOG periodically writes to
a file
(ERR.TMP).
ERRLOG scans the queue and logs the contents at
most 5 seconds after the occurrence of an error, and sooner if a burst
of errors causes the queue to approach its limit.
(The memory
allocation routine determines the amount of space that the queue may
occupy;
see section 2.1.1 above.) The error data queue is cleared
each time ERRLOG logs it contents.

2.2

TASK INTERACTION

The primary function of the error logging tasks is to analyze the
error information gathered by the Executive in order to produce a
report. ERRLOG preserves the Executive's raw information and passes
it on to PSE when that task is activated. PSE prepares the data for
input to SYE, which selectively generates the final, readable report.
The following sections describe the file activity involved in this
task interaction, and Figure 2-2 demonstrates the file activity in a
flow chart.
The error logging system on RSX-llM uses various defaults for its
files.
The default device and directory are SY0: and [1,6]. The
tasks use several standard filenames {including ERR.TMP, ERROR.TMP and
ERROR.SYS).
Users should not attempt to override these defaults
{although it is possible to do so in some cases).
One exception,
however, is the device to which ERRLOG writes the raw data file
ERR.TMP; it may be desirable to specify a dedicated, non-system
device for this file.
(This would be necessary, for instance, if the
ERR.TMP files had to be analyzed at a different installation.)

2-3

HOW ERROR LOGGING WORKS

TASK INTERACTION

E
R
R
L
0
G

OPERATOR
RUNS PSE

A -------- s

RENAME
ERR.TMP FILE

ERR.TMP

REQUEST
ERR.TMP
FILE
PRE2 ANALYZE
RAW DATA

ERROR.TMP

ERROR.SYS

OPERATOR
RUNS SYE

A - - - - - - - - . i yE

SELECTIVELY
ANALYZE
ERROR.SYS
CONTENTS

LISTING
FILES

ERROR LOG
REPORTS

Figure 2-2

Task Interaction

2-4

HOW ERROR LOGGING WORKS
2.2.1

ERRLOG Files (ERR.TMP and ERROR.TMP)

Each time ERRLOG is initialized (usually at System Startup), it
creates a file called ERR.TMP and writes in system configuration
information needed eventually by PSE. ERRLOG then periodically writes
to the file the information it obtains from the Executive error
message queue (see section 2.1.3).
By default, the
data
is
transferred to [l,6]ERR.TMP by means of LUN 4, assigned to SY0: at
task build. [1,6] and ERR.TMP are the only valid values for the
directory and filename, but the device field may be changed (in which
case, the LUN assignment would also have to be changed) at task build.
See section 5.4.2. (The line in the file ERLBLD.CMD that assigns SY0:
to LUN 4 is "ASG=SY:4". A user could edit the assignment to read
"ASG=DK2:4", for example. Otherwise, the REA command could be used to
reassign the LUN.
The REA command is described in the RSX-llM
Operator's Procedures Manual.)
When the user runs PSE, ERRLOG renames the raw data file to ERROR.TMP,
makes it available to PSE and then creates a new ERR.TMP file, which
includes the required system configuration information.
Only one
ERR.TMP file should exist at any given time. There might be more than
one if the system has crashed or been shut down improperly.
In this
case, use PIP to change the name to ERROR.TMP, but be careful to
preserve the correct version number order.

2.2.2

PSE File (ERROR.SYS)

PSE (the Error File Preanalyzer) requests the file ERROR.TMP from
ERRLOG, analyzes the raw error data, creates a file called ERROR.SYS
and then deletes ERROR.TMP. If one or more ERROR.SYS files already
exist, PSE appends the newly pre-analyzed data to the highest version.
The data in ERROR.SYS is in a format that SYE can use to generate its
reports.
When supplying the PSE command line, the user can override the output
file's default device, directory and filename (SY0: [l,6]ERROR.SYS),
but such changes are not recommended~
(Note that the input file
specified in the SYE command line must be the same as the PSE output
file; see sections 3.2 and 3.3.)

2.2.3

SYE Report Files

The output file from PSE becomes the input file to SYE. The name of
the output file that SYE produces after analyzing the contents of
ERROR.SYS is automatically generated and depends on the command line
options issued to the task (see section 3.3).
See Chapter 4 for a detailed description of the listing files that SYE
generates, the end product of the RSX-llM error logging subsystem.

2-5

CHAPTER 3
OPERATING PROCEDURES

This chapter describes the operating procedures for
the
three error
logging and analysis tasks (ERRLOG, PSE and SYE) and for the task that
terminates error logging (ERF).
The error logging subsystem must be
properly generated
into the system before the user can invoke these
tasks (see Chapter 5).
Error logging requires very little operator
intervention.
After
it has been activated either explicitly by the
operator from a privileged terminal or automatically by a command
in
the system startup command file, its operation is transparent to the
user until error logging reports need to be generated.
Each error logging task issues a

message whenever
it encounters a
it is logging)
that halts or
interferes with the
task's operation.
The
tasks
also
issue
informative messages
(when a
new file
is opened in response to a
request from PSE, for example).
Both kinds of message are listed
for
each task in section 3.5.

condition

3.1

(not

errors

RUNNING ERRLOG (THE ERROR LOGGER)

The task ERRLOG must be permanently installed
(see Chapter
5).
To
activate error logging, initiate ERRLOG from a privileged terminal by
typing:
>RUN ERRLOG
The system startup command file
([l,2]STARTUP.CMD)
may include the
above command.
If so,
error logging is activated automatically at
system startup.
Note that ERRLOG requires that the directory [1,6] exist on the system
disk.
If it does not exist, ERRLOG returns the following message:
ERL -- GET DIRECTORY ID FAILED, CODE -26
Then issue the following command to create the necessary directory:
>UFD SY:[l,6]

3.2

RUNNING PSE (THE PRE-ANALYZER)

There are three ways to run the pre-analyzer task PSE.
run from a privileged terminal.)

3-1

(PSE

must

OPERATING PROCEDURES
1.

To install and run PSE in an unmapped system, type:
>INS [l,50]PSE
>PSE

To install and run PSE in a mapped system, type:
>INS [l,54]PSE
>PSE

To install, run and remove PSE in either a mapped or an
unmapped system if the conditions described in section 5.5
have been met, type:
>RUN $PSE

wnen installing or running
PSE
by
method
3
above
in
a
system-controlled partition, append the /INC=xxx switch to the command
line to increment the amount of space available to the task.
PSE
needs additional space at the rate of 10(decimal) words per unit,
where a unit is each device that could cause a loggable error.
When
running in a user-controlled (task) partition, PSE itself determines
the amount of space available and then uses the amount of space it
needs.
The pre-analyzer task responds with the prompt PSE> and waits for the
user to type a command line. The format of the PSE command line is:
outdev:[ufd]file.typ=indev:
where the output file is described by a standard RSX-llM file
specifier.
The input file specifier (indev:) consists only of the
input device since the filename (assigned by the task ERRLOG) is
always ERROR.TMP and the UFO is always [1,6].
If PSE has been explicitly installed (items 1 and 2 above), both the
call to PSE and the file specifiers may be included on the same line~
that is:
>INS [ 1, 50] PSE
>PSE outdev: [ufd]file.typ=indev:
The defaults for omitted fields of the output file specifier are:
Field

Default

outdev:

SY0:

ufd

[ l, 6 J

file

ERROR

.typ

.SYS

The default for indev:

is SY0:

To use all the defaults for both the input and output file specifiers,
press the carriage return key in response to the PSE> prompt. When
PSE prompts again, type CTRL/Z to return to MCR.

3-2

OPERATING PROCEDURES
Example:
>INS [l,54]PSE
>PSE
PSE> SY:=SY:
PSE> "z
>REM PSE

3.3

; INSTALL PSE
:RUN PSE
;GENERATE PRE-ANALYZED FILE
;EXIT FROM PSE
;REMOVE PSE

RUNNING SYE (THE ERROR LOG ANALYZER)

There are three ways to run the error log analyzer task SYE.
See
Chapter 4 for a detailed description of the reports generated by SYE.
1.

To install and run SYE in an unmapped system,
following commands at a privileged terminal:

type

the

>INS [1,50] SYE
>SYE
To install and run SYE in a mapped system, type the following
commands at a privileged terminal:

>INS [l,54]SYE
>SYE
To install and run SYE in either a mapped or an unmapped
system if the conditions described in section 5.5 have been
met, type the following command at any terminal:

>RUN $SYE
The analyzer task responds with the prompt SYE> and waits for the user
to type a command line. The format of the command line is
outdev: [ufd]=indev:[ufd]file.typ/switchl ••• /switchn
T,i::.

J..L.

,..,,,n

0.I..C.

1---

Udl:)

'----

Uli:!li:!U

____ .,,:_,:.L.., ...
li:!Xf:J.L.Ll;.;J.!;..L::f

.L._,.,_,..:1

,: __
.LUl:il..d..l.J.li:!U

l.!.L.---

\ .LL.l;:llll:i

--..:t

d.llU

""l
~

-1-----\

Cll.JVV~J,

1--.L.'-

uvi...u

.&.t....-

i...u1::

call to SYE and the file specifiers may be included on the same line;
that is:
>INS [l,50]SYE
>SYE outdev: [ufd]=indev:[ufd]file.typ/switchl ••• /switchn
Note that the output filename and type are not included in the output
file specifier. The filename corresponds to the values specified for
xxx and yyy for the /BR: switch described below. The file type is
LST.
The input file is described by a standard RSX-llM file specifier;
it
must be a file previously created as an output file by PSE (see
section 3. 2) •
The default values for the output file specifier are:
Default
outdev:

SY0:

ufd

user uic
3-3

OPERATING PROCEDURES
The default values for the input file specifier are:
Field

Default

indev:

SY0:

uf d

[ 1'6]

file

ERROR

.typ

.SYS

switches

/BR:ALLSUM/NODE/SU

To use all the defaults for both the input and the output file
specifiers, press the carriage return key in response to the SYE
prompt. When SYE prompts again, type CTRL/Z to return to MCR.
For
example:
SYE> <CR>
SYE> "z

>
The following switches may be appended to the input file specifier
define the generated error log reports:
Switch
/BR:xxxyyy

Description
The /BR:
(breakdown) switch determines
what
information is to be included in the report. The
output filename is derived from
the
values
assigned to xxxyyy. The output file type is LST.
xxx can have one of the following values:
ALL

Include error statistics
and DECtape units.

for

all

disk

NOTE
ALL is
xxx.

the

default

value

for

DEV

Include
only
statistics.

OSK

Include only error
disk units.

OTO

Include only error statistics related to
interrupt timeouts.

MAG

Include only error
DECtape units.

statistics

SYS

Include statistics
errors only.

UDI

Include
statistics
interrupt errors only.

3-4

device-detected
statistics

error
for

for

all

system-related
for

undefined

OPERATING PROCEDURES
yyy can have one of the following values:
ALL

Include both
individual
error
summary information in the report.

and

DSK

Include only disk errors in the report.
(Only valid when xxx is ALL, DEV or
DTO.)

MAG

Include only DECtape
report.
(Only valid
DEV or D'I'O.)

SUM

Include only the summary information
the report.

errors in
the
when xxx is ALL,
in

NOTES

/BG:time:date

SUM is the
for yyy.

default

value

When yyy is either DSK or
MAG, task SYE produces both
individual
error
and
summary information in its
report.

(BeGin with.) Include in the report only those
errors that occurred on or after the specified
time and date. The format of the time and date is
hh:mrn:ss:mm:dd:yy
where all the numbers are
fields must be specified.

decimal

and

all

six

/BG:20:30:0:3:20:76

includes those errors
occurred after 8:30 PM on March 20, 1976.

that

The default is to include all errors of
specified type, no matter when they occurred.

the

Produce a detailed report that
following additional information:

the

Example:

/DE

includes

-Description of the device error register bits
-The task and function that caused the error
-Statistics about the device that caused the error
-Information about concurrent UNIBUS activity
The default is /-DE or /NODE.
/DV:dev[n]

Include in the report only those errors
occurred on a specified device type or
specified device unit.

that
on a

Examples:
/DV:DK requests that error statistics on all
or RK05 units be provided
3-5

RK03

OPERATING PROCEDURES
/DV:DKl requests that only the error
for RK03 or RK05 unit 1 be provided.
/ED:time:date

statistics

(End Date.)
Include
in the report only those
errors that occurred at or before the specified
time and date.
The format of the time and date is
hh:mm:ss:mm:dd:yy
where all the numbers are
fields must be specified.

decimal

and

all

six

Example:
/ED:l8:0:0:3:22:76
includes those errors
occurred before 6:00 PM on March 22, 1976.

that

The default is to include all errors of
specified type, no matter when they occurred.

the

Include summary information in the report.

/SU

The default is /SU.
Do not include summary information in the report.

/-SU or
/~OSU

The default is /SU.
SYE command line examples:
1.

>SYE LP:=SY0:[1,6]ERROR.SYS/BR:DTOMAG/DE
The command line requests a detailed error report to be
output on the line printer.
The /BR:
switch instructs SYE
to describe interrupt timeout errors (DTO) that occurred on
DECtape units (MAG). The report will include both individual
error descriptions and a summary description.

>RUN $SYE
SYE> SY0:=SY0:/BR:ALLALL
SYE> AZ
The /BR:
switch instructs SYE to produce an error report on
all the errors described in ERROR.SYS {the default filename
in the SYE command line). The report will be stored
in a
listing file on the system disk, and it will contain both
individual error descriptions and a summary description.

>RUN
SYE>
SYE>
SYE>

$SYE
LP0:=SY0:/BG:20:45:00:05:22:76/BR:UDISUM
LP0:=SY0:/BR:DTODSK/ED:06:30:00:05:24:76

The first command line instructs SYE to produce on the line
printer a summary description only of all undefined interrupt
errors that occurred on or after 8:45 PM on May 22, 1976.
The second command line requests a report on interrupt
timeout errors related to disks that occurred on or before
6:30 AM on May 24, 1976. The second report, also output on
the line printer, will
include both
individual
error
descriptions and a summary description.

3-6

OPERATING PROCEDURES
3.4

RUNNING ERF (THE SHUTDOWN TASK)

To terminate error logging, run the task ERF by typing one of the
following commands or pair of commands from a privileged terminal:
1.

For an unmapped system:
>INS [l,50]ERF
>ERF

For a mapped system:
>INS [l,54]ERF

>ERF
3.

For either a mapped or an unmapped system if
described in section 5.5 have been met:

the

conditions

>RUN $ERF

3.5

3.5.1

ERROR LOGGING TASK MESSAGES

ERRLOG Messages

3.5.1.1 Informational Messages - The following two
messages
informational messages issued during ERRLOG's normal operation.

are

ERL -- ERROR LOG INITIALIZED
The file ERR.TMP has been opened and initialized successfully.
The message occurs either when error logging is first initialized
or after ERRLOG has opened a new file after passing its previous
file to PSE.
ERL -- LOGGING ENDED AFTER ddd ERRORS
ERRLOG issues this message when error logging is shut down, where
"ddd" is the number of errors that were logged to the current
file. This count will have been zeroed if PSE had received a
file from ERRLOG while logging was active; therefore it does not
necessarily indicate the total number of errors logged since
ERRLOG was initialized.

3.5.1.2 Error Messages - The error logging
subsystem
terminates
itself in response to an error condition unless the description of the
associated error message states otherwise. In messages which contain
one or more error codes, the codes are File Control Service (FCS) or
driver/File Control Primitive (FCP) error return codes obtained from
the File Descriptor Block (FDB) at the time of the error. If the code
is displayed as negative, it was generated by the driver or FCP.
If
displayed as positive, the code represents an FCS error. All error
codes are decimal numbers. See the IAS/RSX-11 I/O Operations Reference
Manual, Appendix I, for a description of the error code.
3-7

OPERATING PROCEDURES
ERL -- ASSIGN LUN FAILURE
An error occurred when ERRLOG tried to assign LUN
creating file ERR.TMP. Logging is not initialized.
ERL -- DEVICE FULL.
THEN "RUN ERRLOG"

while

MOUNT NEW VOLUME OR ERL -- "REA ERRLOG 4 DDU:",

while trying to write an error to the file, ERRLOG found the
device full. The buffer containing the most recent error logged
is requeued in memory, and error logging is shut down.
In order
to reinitialize logging, either a different device with available
space must be used, or the full volume must be DMOunted, a new
one MOUnted and the task ERRLOG restarted; the system will then
reinitialize error logging.
(There may be errors queued in the
dynamic pool ready to be logged.)
ERL -- DEVICE RECORD PUT ERROR, CODE ddd
During ERR.TMP initialization, a file system error
in writing a device configuration record.

was

detected

ERL -- ERROR ON REOPEN, CODE ddd
ERRLOG was unable to open an existing, initialized
in order to write an error message to it.
ERL -- ERR.TMP NOT RENAMED (ERR.TMP:

ddd, ERROR.TMP:

ERR.TMP

file

ddd)

ERRLOG failed to rename the ERR.TMP file either when passing the
file contents to PSE or when error logging was being shutdown.
The codes are from the respective files' FDBs; the code may be 0
for ERROR.TMP, indicating the problem was only with ERR.TMP. In
this case, error logging is not shutdown since a new file will be
created.
Once the reason for the rename failure is determined,
the file may be renamed using PIP, and subsequently analyzed (see
the RSX-llM Utilities Procedures Manual).
ERL -- ERR.TMP OPEN FAILURE, CODE ddd
The file system failed during initialization when ERRLOG tried to
create the file ERR.TMP.
ERL -- FILE CLOSE ERROR, CODE ddd
After ERRLOG had written initialization information or error
records, FCS returned an error when it tried to close ERR.TMP.
The file will be locked and truncated;
error records may
therefore be missing from the end of the file.
Use PIP to unlock
the file for analysis or for further logging if the error is not
persistent (see the RSX-llM Utilities Procedures Manual).
ERL -- GET DIRECTORY ID FAILED, CODE ddd
Failure during creation of a new ERR.TMP file.
If the code is
-26, the directory [l,6] does not exist on the system disk. See
Section 3.1 above.
ERL -- INITIALIZATION PUT ERROR, CODE ddd
During file initialization, an error
attempt to write to the ERR.TMP file.

3-8

occurred

the

first

OPERATING PROCEDURES
ERL -- MARKED FOR REMOVE, LOGGING NOT STARTED
ERRLOG must be permanently installed;
therefore it may not be
executed by the default "install/request/remove" method of MCR.
This message will appear if the command RUN $ERL has been
issued
to start up error logging.
ERL -- NO ERROR FILE
This error is unlikely to occur.
It indicates that some task has
zeroed an internal
file
ID pointer.
ERRLOG exits when it
encounters this situation.
Rerun ERRLOG to activate error logging.
ERL -- OUTPUT ERROR, CODE ddd
This error was caused by an attempt to write data
ERR.TMP after the occurrence of a loggable error.

the

file

ERL -- TASK NAME NOT "ERRLOG"
initialize ERRLOG
This message appears when the user
tries to
The error logging
after the task has been installed incorrectly.
task must be installed under the name "ERRLOG".
ERL -- TERMINAL NOT PRIVILEGED
The terminal from which ERRLOG is initialized must be privileged.

3.5.2

PSE Messages

PSE

COMMAND STRING PARSE ERROR
PSE encountered a syntax or
input command line.
PSE prompts for further

semantic

input.

error

Retype

when

the

examining

corrected

command

line.
PSE -- DELETE ERROR ON INPUT FILE
When PSE finished processing the input file ERROR.TMP,
was unable to delete it.

the

task

PSE was able to communicate with ERRLOG, but ERRLOG did not
a file available within 30 seconds.

make

PSE -- ERROR LOGGER DID NOT PROVIDE A FILE

Run PSE again.
PSE -- lST RECORD WAS NOT AN
PRE-ANALYZED

INITIALIZATION

RECORD

FILE

CANNOT

The first record of a file must be an initialization record.
Both the
input and the output files are closed.
The input file
is not deleted.
Rerun PSE.
If the error occurs again, delete the oldest
of ERROR.TMP.

3-9

version

OPERATING PROCEDURES
PSE -- INPUT FILE ERROR
An error was encountered when PSE tried to open or obtain data
from
the
input file ERROR.TMP.
The input and output files are
closed.
The input file ERROR.TMP is not deleted.
Try to analyze the file again.
PSE -- OUTPUT DEVICE IS FULL
The output device became full while PSE was writing to the output
file.
Both the input and output files were closed.
ERROR.TMP is
not deleted.
Select another volume for the output file.
PSE -- OUTPUT FILE ERROR
An error was encountered while PSE was accessing the output file.
Both the
input and output files are closed.
ERROR.TMP is not
deleted.
PSE -- RECORD SIZE WAS INCORRECT
When PSE reads a record from the input file, it verifies the size
of the record.
If the size is wrong, it ignores the record and
continues to process the rest of the input file.
PSE -- TERMINAL MUST BE PRIVILEGED
An attempt was made to run PSE from a non-privileged terminal.
Run PSE from a privileged terminal.
PSE -- TOO MANY DEVICE DESCRIPTOR ENTRIES.
A LARGER PARTITION
DEVICE = device
IDENTIFIER = id

RECOMMEND THAT PSE RUN

PSE has run out of storage space
in which to hold descriptor
entries for
the device named in the message.
PSE continues to
process the input file, but it is unable to process any more
errors for the named device.
In the future,
run PSE for
this configuration in a
larger
partition, or
specify the /INC=xxx switch when PSE is installed
in a system controlled partition.
PSE requires 10
(decimal)
words of space for each device for which errors are to be logged.
PSE -- UNABLE TO CLOSE THE INPUT FILE
PSE is unable to close the input file ERROR.TMP.
deleted.

The file is not

PSE -- UNABLE TO CLOSE THE OUTPUT FILE
PSE is unable to close the output file.
The message generally
indicates that the output device is full and that the last block
of the file will be missing.
PSE -- UNABLE TO FIND ANY ERROR.TMP FILES
PSE cannot locate any files named ERROR.TMP.
Verify that the
correct input device was specified or
that ERRLOG has been
initialized.

3-10

OPERATING PROCEDURES
PSE -- UNABLE TO RECOGNIZE DEVICE IDENTIFIER
IDENTIFIER = id
PSE has received a device descriptor error entry that does not
match any device described in the device tables. PSE ignores
that entry record and continues to process the rest of the file.
PSE -- UNABLE TO RECOGNIZE ERROR ENTRY CODE
ENTRY CODE = code
PSE must recognize the entry code contained within each record in
order to know how to process the record.
If PSE does not
recognize the entry code, it ignores the record and continues to
process the rest of the input file.
PSE -- UNABLE TO REQUEST A FILE FROM ERRLOG
PSE tried to request ERRLOG to make a file available for
formatting.
This error indicates that ERRLOG has not been
initialized.

3.5.3

SYE Messages

3.5.3.1 Command Line Errors - The messages described in this
occur when SYE encounters an error in the command line.

section

SYE -- COMMAND STRING ERROR
ERROR NUMBER x
SYE has encountered an error (otner tnan end of file) when trying
to obtain a command line. See the IAS/RSX-ll I/O Operations
Reference Manual, Appendix I, for an explanation of the error
code "x", a decimal number.
SYE
text

COMMAND STRING ERROR
SYE encountered an error when it tried to parse the command line.
"text" is the command line that contains the error.

SYE
text

COMMAND STRING SYNTAX ERROR
SYE encountered an error in the syntax of the
"text" is the erring portion of the command line.

command

line.

SYE -- ILLEGAL BREAKDOWN SWITCH
/BREAKDOWN:text
Illegal values ("text") have been
(/BR:) switch. See section 3.3.

supplied

with

the

breakdown

3.5.3.2 File Service Errors - The following messages are caused by
file failures. Each message contains the line "FATAL ERROR - x" where
x is a decimal number that represents an error code returned by File
Control Services (FCS). See the IAS/RSX-11 I/O Operations Reference
Manual, Appendix I.

3-11

OPERATING PROCEDURES
SYE -- DEVICE ERROR INPUT FILE
FATAL ERROR - x.
An error (other than end of file) occurred when SYE attempted to
read data from the input file.
SYE closes all files and prompts
for the next command line.
SYE -- DEVICE ERROR OUTPUT FILE
F'ATAL ERROR - x.
SYE encountered an error when attempting to write data to the
output file.
SYE closes all
files
and prompts for the next
command line.
SYE -- OPEN FAILURE ON INPUT DEVICE
FATAL ERROR - x.
SYE encountered an error when it tried to open the
input file.
SYE closes all files and prompts for the next command line.
SYE -- OPEN FAILURE ON OUTPUT DEVICE
FATAL ERROR - x.
t... - an error __WUt!Il

tried to open the output file.
SYE closes all files and prompts for the next command line.
~,,r.i

v.Lr:..

- - - - ... -.L..---...:J
c1n.;v
uu 1...1::: Lev

.ll.

3.5.3.3 Additional Messages - The first message below is an error
message;
the second indicates that SYE has completed its analysis.
SYE -- SUMMARY TABLE OVERFLOW
REPORT CONTINUES WITHOUT SUMMARIES
SYE is unable to produce a summary report because there are too
many devices with associated errors.
SYE produces a report
without the normal summary.
The /BR:
switch should be changed
to reduce the number of erring devices displayed. Alternatively,
SYE could be modified to accommodate more devices.
(See Appendix
A, which describes how to modify SYE by means of the task builder
command file.) Normally the analyzer
is built to handle 40
(decimal) devices.
SYE -- x.
filename

PAGES

SYE displays this message when it has completed its analysis.
Hx."
is the decimal number of pages in the report and "filename"
is the name of the output file containing the report.

3.5.4

ERF Messages

The shutdown task ERF always displays a message in response to a
request to run;
the message
is either an error message or a
confirmation of shutdown.
ERF -- "ERRLOG" NOT INSTALLED
The task ERRLOG has not been installed.

3-12

OPERATING PROCEDURES
ERF -- ERROR LOGGING NOT STARTED
Error logging was not initialized, and therefore does not need to
be shutdown.
ERF -- REQUESTED "ERRLOG" TO STOP LOGGING
The normal confirmation message.
ERF has exited
should display its own termination message shortly.
ERF -- TERMINAL NOT PRIVILEGED
ERF must be requested from a privileged terminal.

3-13

and

ERRLOG

CHAPTER 4
THE ERROR LOG REPORTS

4.1

GENERATING ERROR LOG REPORTS

To generate error log reports, the user must first run the task PSE
from a privileged terminal (see section 3.2).
PSE performs a
preliminary analysis on raw data contained in files created by the
error logging task ERRLOG. The PSE output file, which contains the
pre-analyzed error data, becomes the input file to SYE.
SYE, the Error Log Analyzer, can be run from any terminal.
When the
PSE output file is available, the user must decide what kind of
reports are needed and then select the appropriate switches for the
SYE command line. For example, the user can select a time frame that
the report is to encompass and can specify that the report include
only those errors associated with a certain device type, unit or
volume. See section 3.3 for a description of SYE operating procedures
and all the available command line switch options.
The Analyzer produces an error report in the form of a printed listing
or a listing file. By default, SYE creates a file called ALLSUM.LST
on the system disk; this file contains a summary report of all errors
on disk and DECtape units.

4.2

INDIVIDUAL ERROR REPORTS

Error iogging detects and records three kinds of errors:
interrupts
through unused vectors, device errors and interrupt timeouts (see
Section 1.2.1). This section describes in detail one or more sample
reports on each kind of error.

4.2.1

Reports For Interrupts Through Unused Vectors (Traps)

Figures 4-1 and 4-2 are reports of two interrupts through unused
vectors (such interrupts are also called traps).
The following
description of the two reports refers to each line of text by number,
where the first line described is line 1. The first two lines, offset
by two star lines, give header information about the error:

4-1

THE ERROR LOG REPORTS

***************************************************************
1

TRAP THROUGH LOCATION 0
LOGGED AT 24:FEB:75 14:36:04

ERROR NUMBER 4.

***************************************************************
3
4
5
6

7
8
9

VECTOR THROUGH WHICH TRAP OCCURRED
0
NUMBER OF UNDF. INTR. MISSED WHILE LOGGING THIS ERROR
PROCESSOR STATUS WORD PRIOR TO THIS ERROR
PROGRAM COUNTER PRIOR TO THIS ERROR

0.
000242
045670

VECTORS WITH ACTIVE IO
220
214

Figure 4-1

Error Report of a Trap Through Location 0

***************************************************************
1
2

UNDEFINED INTERRUPT
LOGGED AT 24-FEB-75 14:52:05

ERROR NUMBER 5.

***************************************************************
3
4
5
6

7
8

VECTOR THROUGH WHICH TRAP OCCURRED
240
NUMBER OF UNDF. INTR. MISSED WHILE LOGGING THIS ERROR
PROCESSOR STATUS WORD PRIOR TO THIS ERROR
PROGRAM COUNTER PRIOR TO THIS ERROR
VECTORS WITH ACTIVE IO
220

Figure 4-2

Error Report of an Undefined Interrupt

4-2

2.
000340
043210

THE ERROR LOG REPORTS
e

Line l describes the type of error {TRAP THROUGH
or UNDEFINED INTERRUPT) .

•

Line ~ gives the date and time the
error s sequence number.

error

LOCATION

occurred

and

0
the

The first error to occur after error logging has been initialized is
assigned a sequence number of 1. The sequence number then increments
by 1 every time a loggable error occurs.
The next block of text {lines 3 through 6) contains information
the interrupt:

about

•

Line 3 provides the address of the vector through
interrupt occurred.

which

the

•

Line 4 notes the number of undefined interrupts that occurred
while the system was logging this error.
{This counter
permits the detection of bursts of undefined interrupts
caused by UNIBUS noise corruption.)

•

Line 5 is the processor status word immediately prior to
undefined interrupt.

the

•

Line 6 is the value of the program counter immediately
to the undefined interrupt.

prior

~he last block of data, line 7 onwards, lists
all the vectors with
active data transfers on the UNIBUS at the time of the error. The
list includes the address of the device that caused the error.
The
block headed "VECTORS WITH ACTIVE IO" does not appear in the report if
there was no I/O activity.

4.2.2

Device Error Reports

Figure 4-3 illustrates a typical report for a device error.
(The
figure also serves as a sample interrupt timeout report, since the
report format is identical for both types of error.) The following
description of ~ne repor~ reLers ~u each line of text by number, where
the first line described is line 1.
The first two lines of text, offset by two
information about the error:

star

lines,

give

header

Line 1 describes the type of error (DISK HARDWARE ERROR).

•

Line 2 gives the date and time the
error's sequence number.

error

occurred

and

the

The first error to occur after error logging has been initialized is
assigned a sequence number of 1. The sequence number then increments
by 1 every time a loggable error occurs.

4-3

THE ERROR LOG REPORTS

RSX llM SYSTEM ERROR REPORT COMPILED AT 20-MAY-75 11:00:13

***************************************************************
1
2

DISK HARDWARE ERROR
LOGGED A~ h-MAY-75 15:37:08

***************************************************************
3
4
5

DISK PARAMETERS
UNIT NAME
DEVICE TYPE

10
11
12

DISK REGISTERS AT ERROR TIME
RKDS
004760
RKER
020000
RKCS
140702
RKWC
177406
RKBA
067636
RK:DA
062000

13
14
15
16

ERROR DIAGNOSIS
RECOVERED
WRITE PROTECT
~RITE VIOLATION

RETRIES PERFORMED

18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

USER TASK PARAMETERS
TASK NAME
FllACP
TASK UIC
1,1
PHYSICAL START ADDRESS 60000
USER FUNCTION REQUESTED
WRITE
FUNCTION INTERPRETED FROM REGISTERS
PHYSICAL BUFFER ADDRESS START
TRANSFER SIZE IN BYTES
LOGICAL BLOCK NUMBER AT IO GO
CYLINDER AT IO GO TIME
TRACK AT IO GO TIME
SECTOR AT IO GO TIME
CYLINDER AT ERROR TIME
TRACK AT ERROR TIME
SECTOR AT ERROR TIME
COUNT OF IO IN PROGRESS

34
35

VECTORS WITH ACTIVE IO
220

7
8

Figure 4-3

DKO
RK05/RK03 UNIT-0 CONTROLLER-0
WRITE PROTECT
WRITE VIOLATION

(400)
WRITE
67622
1000
4540
100.
0.
0.

99.
1.
l].

Error Report of a Disk Hardware Error

4-4

THE ERROR LOG REPORTS
The next block of data (DISK PARAMETERS) describes the erring device:
•

Line 4 (UNIT NAME)

shows the device mnemonic and unit

number

{ DK0) •

•

Line 5 (DEVICE TYPE) shows the DIGITAL name for
the device
(RK05/RK03),
the physical unit number on the controller
(UNIT-0) and the controller number (CONTROLLER-0).

The report then describes the state of the device registers at the
time of the error (DISK REGISTERS AT ERROR TIME) in lines 6 through
12. The first column lists the register names;
the second shows the
contents of the registers.
The device register names are those used
in the PDP-11 Peripherals Handbook.
The contents of the registers on
retries are not recorded.
The text at the end of lines 7 and 8
(WRITE PROTECT and WRITE
VIOLATION)
describes the error bits in the device registers named on
those lines. A description of the device error register bits only
appears if the user has specified the /DE (detailed report) switch in
the SYE command line.
•

Line 14 indicates whether or not the Executive error recovery
procedure corrected the error.

•

Lines 15 and 16 repeat the description of the device error
register bits
(see lines 7 and 8).
(This information only
appears in a detailed report.)

•

Line 17 shows how many times the Executive had to retry the
error before it was successfully recovered.
This line
alternatively shows the number of times the Executive retried
the error if recovery was unsuccessful.

The next block of data describes the user task that initiated the
I/O
request that failed.
Only a detailed report will contain this
information:
•

Line 19 provides the 6-character task name (FllACP).

Line 20 is the User Identification Code
the task was running.

(DIC)

•

Line 21 shows the task's physical start
the base address of the task in memory.

address,

•

Line 22 describes the function requested by the task (via a
QIO directive)
at the time of the error. The number in
parentheses at the end of the line is the octal QIO function
code.

•

Line 23 describes the function that was implied by the
contents of the register.
For this error, the implied
function is the same as the function requested by the task
(WRITE).

under

which

that

NOTE
The function implied by the contents of the register
(that is, the function that failed) can differ from
the function requested by the task.
For example, if
a task requests a WRITE to a DECtape, the driver
must perform a READ BLOCK NUMBER function,
which
could then cause an error.
4-5

is,

THE ERROR LOG REPORTS
•

Lines 24 through 33. These 10 lines describe in detail the
device activity at the time of the error. The information
given depends on the type of device being described.
This
report includes the physical memory address of the data
buffer and the transfer size, and the physical device's
start address and estimated end address.

The last block of text {lines 34 and 35) lists the vectors with active
data transfers on the UNIBUS at the time of the error. The list
includes the address of the device that caused the error. The number
on the second line (220)
is the vector address through which a
transfer complete or data error interrupt would be fielded.
A long
list of vector addresses could indicate that UNIBUS interaction caused
the error.
The block headed "VECTORS WITH ACTIVE IO" does not appear if there was
no I/O activity when the error occurred. Also, error reports on
interrupt timeouts do not include this information because the long
time element involved makes it irrelevant.

4.2.3

Interrupt Timeout Reports

Since interrupt timeout reports have the same format as device error
reports, see section 4.2.2 for a description of the various entries.

4.3

SUMMARY REPORTS

Figure 4-4 is an example of a detailed summary. SYE includes detailed
information in a report when the /DE switch has been specified in the
command line. This part of the report provides summary information
about all the errors analyzed in the report as a whole (but not
necessarily about all the errors in the input file to SYE).
The command line issued to SYE determines which errors are to be
analyzed;
the summary displays this command line at the beginning of
the report (see lines 2 and 3).
The next block of information, labelled "REPORT FILE ENVIRONMENT",
describes the SYE input and output files and the time and date of the
first and last entries in the input file (lines 4 through 8).

4-6

THE ERROR LOG REPORTS

RSX llM SYSTEM ERROR REPORT COMPILED AT 20-MAY-75 11:00:39
1

SYSTEM ERROR REPORT SUMMARY (SYSTEM)

2
3

COMMAND LINE USED
LP:=DKl:/BR:ALLALL/DE

10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

REPORT FILE ENVIRONMENT
SOURCE FILE
DKl: [l,6]ERROR.SYS
OUTPUT FILE
LP: (54,24]ALLALL.LST
DATE OF FIRST ENTRY
6-MAY-75 15:21:31
DATE OF LAST ENTRY
6-MAY-75 , 15:50:49
...,
_LL; •
ENTRIES PROCESSED
ENTRIES MISSING
a.
UNKNOWN ENTRIES ENCOUNTERED
0.
UNKNOWN DEVICES ENCOUNTERED
0.
FIELD FORMAT ERRORS ENCOUNTERED
a.
DEVICE ERROR PROCESSED
11.
UNDEFINED INTERRUPTS PROCESSED
0.
UNDF. INTR. MISSED DUE TO UNDF. INTR. PROCESSING
TRAPS THROUGH LOCATION 0 PROCESSED
a.
DEVICE TIMEOUTS PROCESSED
a.
MEMORY MANAGEMENT ERRORS ENCOUNTERED
SYSTEM POWER FAILS ENCOUNTERED
SYSTEM PARITY ERRORS ENCOUNTERED
REPRODUCIBLE
NON REPRODUCIBLE
SYSTEM LOADS
1.

SYSTEM ERROR REPORT SUMMARY

26
27
28

RP03 UNIT-a CONTROLLER-a
HARD
0.
SOFT
1.

SYSTEM ERROR REPORT SUMMARY

3a
31
32

TU56 UNIT-a CONTROLLER-a
HARD
a.
SOFT
5.

33
34
35

TAll UNIT-1 CONTROLLER-a
HARD
a.
SOFT
1.

5
6
7
8
9

Figure 4-4

(DISK - MOVABLE HEAD)

(TAPE)

Summary Error Report

4-7

THE ERROR LOG REPORTS
The next 16 lines provide various error statistics:
•

Line 9 is the
report.

number

error

entries

analyzed

the

Line 10 is the number of errors missed because
the
• occurrence
of another error prevented a previous one from
being logged.
•

Line 11 is the number of unknown errors encountered by the
aoalyz~r.
An unknown error is an entry that a version of
SYE cannot analyze. This situation can occur if an old
version of SYE has been run.

12 is the number of entries that referred to a device
• Line
not supported by the analyzer.
Such an entry may be
encountered if the site has implemented error logging
device that SYE does not recognize.

•

Line 13 is the number of times the input file encountered a
data structure error (field format error). Such encounters
may indicate that the wrong version of the pre-analyzer PSE
was used.

•

Line 14 is the number of
report.

•

Line 15 is the number of undefined
this report.

•

Line 16 is the number of undefined interrupts that were not
logged because another undefined interrupt was already being
recorded.

•

Line 17 is the number of traps through location 0 that
analyzed in this report.

•

Line 18 is the number of interrupt timeouts analyzed in this
report.

•

Lines 19 through 23 are concerned with statistics that will
be applicable to a future version of the error logging
facility.

•

Line 24 (SYSTEM LOADS) is the number of times that error
logging was initiated in the time span covered by the
report. Error logging is usually initiated only once when
the system is loaded and started.

device

errors

analyzed

interrupts

this

analyzed

were

The remaining sections, lines 25 through 35,
summarize
error
statistics according to the associated device type. The types defined
for SYE summary reports are "disks - movable head", "disks - fixed
head" and "tapes". A device type section appears only if the report
analyzes errors associated with that type.
Each section describes:
•

The DIGITAL name for the physical device (RP03 or TU56,
example)

•

The physical unit numbers of the device and
(UNIT-0 and CONTROLLER-0, for example)

•

The number of associated hard (non-recovered)
(recovered) errors analyzed in this report.
4-8

its

for

controller
and

soft

CHAPTER 5
GENERATION PROCEDURES

5.1

INTRODUCTION

This chapter provides all the information needed to generate the error
logging subsystem.
Users should read the instructions carefully
before proceeding to generate error logging for the first time.
The procedures consist of four basic operations:
1.

Selecting error logging options at system generation.

Assembling the privileged tasks ERRLOG and ERF.

Task building all four error logging tasks.

Installing ERRLOG.

The assembly and task build procedures include the use of command
files. If these files need to be modified in any way, the user should
use an editor to do so before starting the procedures (see the RSX-llM
Utilities Procedures Manual).
The files needed to generate the error logging facility can
either

5.2

found

•

On the source tape in the distribution kit for RP02, RP03
RP04 configurations, or

•

On the MCR and FCP source disk in the distribution kit for an
RK05 configuration.

SYSTEM GENERATION OPTIONS

A complete system generation must be performed to incorporate error
logging in an RSX-llM system.
(See the RSX-llM System Generation
Manual for a complete description of system generation procedures.)
The query program SGN (phase 1 of system generation)
includes two
questions that pertain to the error logging facility. The user should
answer yes ("Y") to both these questions in order to include the
necessary Executive features and data structures in the target system.
If the user replies no ("N")
to both these questions, the error
logging facility cannot be generated without performing another
complete system generation.
The relevant questions are described
below.

5-1

GENERATION PROCEDURES
DO YOU WISH TO LOG DEVICE ERRORS AND INTERRUPT TIMEOUTS[Y/N]?
If the answer is yes:
•

The disk and DECtape drivers will be assembled to enable
error logging

•

The formatting routine for device error and interrupt
timeout messages will be included in the Executive

•

The I/O data base will be extended for each controller.

DO YOU WISH TO LOG UNDEFINED INTERRUPTS[Y/N]?
If the answer is yes:
•

The Executive will include vector address identification
routines
and
a
routine for formatting undefined
interrupt error messages.

•

All unused vectors will be filled with pointers
Executive error logging routines.

the

If the answer is no, unused vectors will merely point to
(Return from Interrupt) instruction.

RT!

The user must then complete both phases of system generation and start
up the target system before proceeding to the next step, the assembly
of the privileged tasks ERRLOG and ERF.

5.3

ASSEMBLING ERRLOG AND ERF

Only the two privileged tasks ERRLOG and ERF need to be assembled.
The source files to be assembled are located on the system generation
source volume (see section 5.1) in User File Directory [17,10].
The command files used for assembly, also located on
volume, are found in one of the following directories:
•

[17,20] for unmapped systems

•

[17,24] for mapped systems

the

source

During assembly, the Executive configuration file RSXMC.MAC from phase
1 of system generation must be available under UIC [11,10]. The MCR
command UFO should be used if necessary to create an [11,10] directory
on
the disk being used for the assembly.
RSXMC.MAC contains
conditional assembly parameters.
There are 2 steps in the assembly operation:
1.

Making the source and command files available.

Assembling the tasks ERRLOG and ERF.

The description of each step is divided into subsections when the
detailed instructions vary according to the type of configuration.
Only one subsection is applicable to a single configuration.

5-2

GENERATION PROCEDURES
5.3.l

Preparing for Assembly

This step places the appropriate
correct directories.

source

and

command

files

the

5.3.1.1 Dual RK Disk Configurations - Both the source and the command
files required for
assembly are already on the MCR/FCP source disk.
However the user must transfer to that disk the RSXMC.MAC Executive
configuration file
for
the system on with which error logging will
run.
This file exists on the mapped or unmapped target disk from the
latest
system
generation.
RSXMC.MAC is located
in directory
[200,200].
NOTE
During system generation,
the
file
RSXMC.MAC was copied to UIC [200,200] of
the target system object disk.
Therefore, to prepare for assembly, mount and boot the MCR/FCP source
disk on DK0:
and mount the appropriate target disk on DKl:.
Note
that it may be necessary to install required MCR tasks.
Then issue MCR commands as follows:
>MOU
>SET
>INS
>UFD

DKl:
/UIC=[ll,10]
[l,50]UFD
DK: [11,10]

>RUN $PIP
PIP> =DK1:[200,200]RSXMC.MAC
PIP> "z
>REM ... UFD
Proceed to
completed.

section

5.3.2

when

this

step

has

been

successfully

5.3.1.2 RP02/03/04 Disk With Magnetic Tape Configurations - On
this
type of conf 1gurat1on,
the Executive source and object files are on
the system disk, but the source files for ERRLOG and ERF are on the
FLX format source magnetic tape.
To prepare for assembly, transfer
the ERRLOG and ERF source files {held under UIC [17,10]) to the disk
containing the Executive files.
Note that it may be necessary to
install the File Exchange Utility task FLX.
For example:
>SET /UIC=[l2,10]
>RUN $FLX
FLX> =MT: [12,10]LKLST.MAC
FLX> "z
>SET /UIC=[l7,10]
>RUN $FLX
FLX> =MT:[l7,10]*.MAC
FLX> "z

5-3

GENERATION PROCEDURES
NOTE
If the installation is using a TU16
magnetic tape drive, replace "MT:" with
"MM:". For example:
FLX> =MM: [17,10]*.MAC
Proceed

section

5.3.2

when

this

step

has

been

successfully

-- . ··r-----·

l"'t'\mnl a.+·on

5.3.l.3 RK Disk With RX Flexible Disk Configurations - On this type
of configuration, the user must load the RX disk driver, mount the RX
disk containing the current RSXMC.MAC configuration file (from phase l
of system generation), then copy the file RSXMC.MAC to UFD [11,10] on
the MCR/FCP source disk mounted on DK0:. If the configuration file
RSXMC.MAC is not currently available on an RX flexible disk, the file
can be found either:
•

on the object disk in directory [200,200], or

•

on the Executive source disk in directory [11,10]

Note that it may be necessary to install required MCR tasks.
Example:
>LOA DX:
>MOU DX:
>SET /UIC=[ll,10]
>INS [l,50]UFD
>UFD DK: [11,10]
>REM •.. UFD
>RUN $PIP
PIP> =DX:[l,2x]RSXMC.MAC
PIP> "'z
where x in the last input file directory is 0 for an
and 4 for a mapped system.
Proceed to
completed.

section

5.3.2

when

this

step

has

unmapped
been

system

successfully

5.3.1.4 RK Disk With DECtape/Cassette/Magnetic Tape Configurations The same set of pre-assembly instructions applies to all three of the
configurations described in this heading.
The system disk should be the MCR/FCP source volume from the
distribution kit.
The appropriate device driver must be loaded and
the volume containing the configuration file RSXMC.MAC for the current
Executive must be available.
Then use FLX to copy RSXMC.MAC to
UFO [11,10] on the system disk. Note that it may be necessary to
install required MCR tasks, such as UFD.
If the configuration file RSXMC.MAC is not currently
non-disk volume, the file can be found either:

available

•

on the object disk in directory [200,200], or

•

on the Executive source disk in directory [ll,10)
5-4

GENERATION PROCEDURES
In the following example, replace nn with the appropriate device
(DT for DECtape, CT for cassette, MT or MM for magnetic tape).

name

>LOA nn:
>INS [l,50]UFD
>UFD DK: [11,H'l]
>REM ..• UFO
>SET /UIC=[ll,10]
>RUN $FLX
FLX> =nn: [l,2x]RSXMC.MAC
FLX> "z
where x in [l,2x] is 0 for an unmapped
system.

system

and

Proceed to
completed.

step

has

been

5.3.2

section

5.3.2

when

this

for

mapped

successfully

Assembly

The following assembly instructions apply to all configurations.
The first step is to set the UIC either to [17,20]
for an unmapped
system or to [17,24] for a mapped system. The [17,20] or [17,24]
directory must not contain any object modules; if necessary, use PIP
to delete any such files.
The next step is to assemble the ERRLOG source files by means of an
indirect command file (@ERLASM)
that issues commands to the MACRO
assembler. The resultant object modules are then concatenated into a
single object file called ERL.OBS. Old object files are then deleted,
and ERL.OBS is renamed ERL.OBJ.
Another indirect command file (@ERFASM) completes the operation
instructing the MACRO assembler to assemble the ERF source file.

For example:
>SET /UIC=[l7,2x]
>RUN $PIP
PIP> *.OBJ;*/DE
PIP> "z
>RUN $BIGMAC
MAC> @ERLASM
MAC> "z
>RUN $PIP
PIP> ERL.OBS=*.OBJ
PIP> *.OBJ;*/DE
PIP> .OBJ/RE=ERL.OBS
PIP> "z
>RUN $BIGMAC
MAC> @ERFASM
MAC> "z
where x in [17,2x] is 0 for an unmapped system
system.

5-5

and

for

mapped

GENERATION PROCEDURES
5.4

TASK BUILDING

In order to build the error logging tasks,
the object and other
necessary files must be transferred to the correct target disk.
Therefore the task building operation consists of two steps:
1.

Transferring the error logging files to the appropriate disk.

Building the tasks.

5.4.1

Transferring the Object Files

The file transfer instructions depend on the type of configuration.
In all cases, however, the commands described transfer to the correct
disk the libraries, command files and overlay description files needed
to build PSE and SYE, and the object module files, command files and
overlay description files needed to build ERRLOG and ERF.

5.4.l.l

Dual RK Disk Configurations - Firstly, mount the mapped
and the MCR/FCP source disk on DKl:.

unmapped object disk on DK0:

If the system is mapped, set the UIC to
[1,20]
for non-privileged
tasks and files, and to [l,24] for privileged tasks and files.
{See
the second example below.) If the system is unmapped, set the UIC to
[1,20]
for both privileged and non-privileged tasks and files.
Then
use PIP to transfer the files to DK0:.
For an unmapped system:
>MOU DKl:
>SET /UIC=[l,20]
>RUN $PIP
PIP> =DKl:PSEBLD.ODL,SYEBLD.ODL,PSE.OLB,SYE.OLB
PIP> =DKl:PSEBLD.CMD,SYEBLD.CMD,ERLBLD.*,ERFBLD.*
PIP> =DK1:[17,20]ERL.OBJ,ERF.OBJ
PIP> AZ
For a mapped system:
>MOU DKl:
>SET /UIC=[l,20]
>RUN $PIP
PIP> =DKl:PSEBLD.ODL,SYEBLD.ODL,PSE.OLB,SYE.OLB
PIP> AZ
>SET /UIC=[l,24]
>RUN $PIP
PIP> =DKl:PSEBLD.CMD,SYEBLD.CMD,ERLBLD.*,ERFBLD.*
PIP> =DK1:[17,24]ERL.OBJ,ERF.OBJ
PIP> AZ
Proceed to section 5.4.2.

5-6

GENERATION PROCEDURES
5.4.1.2 RP02/03/04 Disk With Magnetic Tape Configurations - On
this
type of configuration, the required non~privileged object libraries
and all command files reside on the distribution kit FLX format source
magnetic tape.
The privileged object files are already on the disk.
The following commands transfer the remaining files to the system disk
and set up the proper UICs.
NOTE
If the installation's magnetic
tape
drive is a TU16, use MM instead of MT in
the following examples.
For unmapped

sys~ems:

>SET /UIC=[l,20j
>RUN $PIP
PIP> =[17,20]ERL.OBJ,ERF.OBJ
PIP> AZ
>RUN $FLX
FLX> =MT: [l,20]PSEBLD.CMD,SYEBLD.CMD,ERLBLD.*,ERFBLD.*
FLX> =MT:[l,20]PSEBLD.ODL,SYEBLD.ODL,PSE.OLB,SYE.OLB
FLX> AZ
For mapped systems:
>SET /UIC=[l,24]
>RUN $PIP
PIP> =[17,24]ERL.OBJ,ERF.OBJ
PIP> AZ
>RUN $FLX
FLX> =MT: [l,24]PSEBLD.CMD 1 SYEBLD.CMD,ERFBLD.*,ERLBLD.*
FLX> AZ
>SET /UIC=[l,20]
>RUN $FLX
FLX> =MT: [l,20]PSEBLD.ODL,SYEBLD.ODL,PSE.OLB,SYE.OLB
FLX> AZ
Proceed to section
successfully.

5.4.2

when

the

transfer

has

been

completed

5.4.1.3 RK Disk With RX Flexible Disk Configurations - On this type
of configuration, the user must transfer the required files to the
object disk in two phases:
1.

Copy the files from the MCR/FCP
flexible disk.

source

disk

Then copy the files from the flexible disk to the
unmapped object disk.

scratch

mapped

5-7

transfer

GENERATION PROCEDURES
For an unmapped system:
>OMO DX:
>INS [l,50]INI
>INI DX:
>REM •.. INI
>MOU DX:
>INS [l,50]UFD
>UFO DX: [l,20]
>SET /UIC=[l,20]
>RUN $PIP
PIP> DX:=PSE.OLB,SYE.OLB,PSEBLD.ODL,SYEBLD.ODL
PIP> DX:=PSEBLD.CMD,SYEBLD.CMD,ERFBLD.*,ERLBLD.*
PIP> DX:=[l7,20]ERL.OBJ,ERF.OBJ
PIP> "z
Now bring down the system, remove the
unmapped object disk and reboot.

MCR/FCP

disk,

mount

the

have

been

mount

the

have

been

>SET /UIC=[l,20]
>MOU DX:
>RUN $PIP
PIP> =DX:*.*
PIP> "z
Proceed to section 5.4.2
successfully transferred.

when

all

the

files

For a mapped system:
>OMO DX:
>INS [l,50]INI
>INI DX:
>REM •.• INI
>MOU DX:
>INS [l,50]UFD
>UFO DX: [l,20]
>UFO DX:[l,24]
>SET /UIC=[l,20]
>RUN $PIP
PIP> DX:=PSE.OLB,SYE.OLB,PSEBLD.ODL,SYEBLD.ODL
PIP> "z
>SET /UIC=[l,24]
>RUN $PIP
PIP> DX:=PSEBLD.CMD,SYEBLD.CMD,ERLBLD.*,ERFBLD.*
PIP> DX:=[l7,24]ERL.OBJ,ERF.OBJ
PIP> "z
Now bring down the system, remove the
mapped object disk and reboot.

MCR/FCP

disk,

>SET /UIC=[l,20]
>MOU DX:
>RUN $PIP
PIP> =DX:*.*
PIP> "z
>SET /UIC=[l,24]
>RUN $PIP
PIP> =DX:*.*
PIP> "z
Proceed to section 5.4.2
successfully transferred.

when

5-8

all

the

files

GENERATION PROCEDURES
5.4.1.4 RK Disk with DECtape or Magnetic Tape Configurations - On
this type of configuration, the user must transfer the required files
to the object disk in two phases:
1.

Copy the files from the MCR/FCP disk
{either DECtape or magnetic tape).

Then copy the files from the tape to the mapped
object disk.

scratch
or

tape

unmapped

Between these two phases, the user must bring down the system and
remove the MCR/FCP disk; then reboot the system with the object disk
mounted on DK0: to complete the transfer.
The following examples demonstrate how to effect the transfer on
either a mapped or an unmapped system. Where the commands use nn to
represent a device name, insert the appropriate name for
the
installation (DT for DECtape, MT or MM for magnetic tape).
For an unmapped system:
>SET /UIC=[l,20]
>RUN $FLX
FLX> nn:/ZE
FLX> nn:/DO=PSEBLD.ODL,SYEBLD.ODL,PSE.OLB,SYE.OLB/RS
FLX> nn:/DO=PSEBLD.CMD,SYEBLD.CMD,ERLBLD.*,ERFBLD.*/RS
FLX> nn:/DO=[l7,20]ERL.OBJ,ERF.OBJ/RS
FLX> ".-,/J
Now bring down the system, remove the
unmapped object disk and reboot.

MCR/FCP

disk,

mount

the

have

been

mount

the

>SET /UIC=[l,20]
>RUN $FLX
FLX> =nn:*. *
FLX> "z
Proceed to section 5.4.2
successfully transferred.

when

all

the

files

For a mapped system:
>SET /UIC=[l,20]
>RUN $FLX
FLX> nn:/ZE
FLX> nn:/DO=PSEBLD.ODL,SYEBLD.ODL,PSE.OLB,SYE.OLB/RS
FLX> "z
>SET /UIC=[l,24]
>RUN $FLX
FLX> nn:/DO=PSEBLD.CMD,SYEBLD.CMD,ERLBLD.*,ERFBLD.*/RS
FLX> nn:/DO=[l7,24]ERL.OBJ,ERF.OBJ/RS
FLX> "z
Now bring down the system, remove the
mapped object disk and reboot.

MCR/FCP

The exact commands to be issued for
according to the type of configuration.

5-9

the

disk,
next

step

differ

GENERATION PROCEDURES
Magnetic tape configurations require the following commands:
>SET /UIC=[l,20]
>RUN $FLX
FLX> =nn:*.*
FLX> "z
>SET /UIC=[l,24]
>RUN $FLX
FLX> =nn:*.*
FLX> "z
where nn is MM or MT.
DECtape configurations require the following commands:
>SET /UIC=[l,20]
>RUN $FLX
FLX> =DT:PSEBLD.ODL,SYEBLD.ODL,PSE.OLB,SYE.OLB
FLX> "z
>SET /UIC=[l,24]
>RUN $FLX
FLX> =DT:PSEBLD.CMD,SYEBLD.CMD,ERLBLD.*,ERFBLD.*
FLX> =DT:ERL.OBJ,ERF.OBJ
FLX> "z
Proceed to section 5.4.2
successfully transferred.

when

all

the

files

been

have

5.4.1.5 RK Disk with Cassette Configurations - On
this
type
of
configuration, the user must transfer the required files to the object
disk in two phases:
1.

Copy the files from
scratch cassettes.

the

MCR/FCP

source

Then copy the files from the cassettes
unmapped object disk.

onto

disk
the

onto

three

mapped

effect

the

transfer

For an unmapped system:
Mount the first cassette.
>SET /UIC=[l,20]
>RUN $FLX
FLX> CT0:/ZE
FLX> CT0:/DO=PSEBLD.ODL,SYEBLD.ODL,PSE.OLB/RS
FLX> CT0:/DO=PSEBLD.CMD,SYEBLD.CMD,ERLBLD.*,ERFBLD.*/RS
FLX> CT0:/D0=[17,20]ERL.OBJ,ERF.OBJ/RS

5-10

GENERATION PROCEDURES
Mount the second cassette.
FLX> CT0:/ZE
FLX> CT0:/DO=SYE.OLB/RS
FLX -- END OF VOLUME ON CASSETTE
CT0: [1,20]
MOUNT NEW CASSETTE? (Y, Z (OUTPUT ONLY), OR CR)
Mount the third cassette.
FLX> Z
("Z" instructs FILEX to initialize
continue the copy operation.)
FLX>

the

new

cassette

and

then

disk,

mount

the

have

been

Now bring down the system, remove the MCR/FCP
unmapped target disk on DK0: and reboot.
Mount the first cassette.
>SET /UIC=[l,20]
>RUN $FLX
FLX> =CT0:*.*
Mount the second cassette.
FLX> =CT0:*.*
FLX -- END OF VOLUME ON CASSETTE
CT0:[1,20]*.*
MOUNT NEW CASSETTE? (Y, Z (OUTPUT ONLY), OR CR)
Mount the third cassette.
FLX> Y

("Y" instructs FILEX to continue the copy operation.)
FLX>

Proceed to section
transferred.

5.4.2.

when

all

the

files

For a mapped system:
Mount the first cassette.
>SET /UIC=[l,24]
>RUN $FLX
FLX> CT0:/ZE
FLX> CT0:/DO=PSEBLD.CMD,SYEBLD.CMD,ERLBLD.*,ERFBLD.*/RS
FLX> CT0:/DO=[l7,24]ERL.OBJ,ERF.OBJ/RS
FLX> . . Z
Mount the second cassette.
>SET /UIC=[l,20]
>RUN $FLX
FLX> CT0:/ZE
FLX> CT0:/DO=PSEBLD.ODL,SYEBLD.ODL,PSE.OLB,SYE.OLB/RS
FLX -- END OF VOLUME ON CASSETTE
CT0: [ 1, 20]
MOUNT NEW CASSETTE? (Y, Z (OUTPUT ONLY), OR CR)
5-11

GENERATION PROCEDURES
Mount the third cassette.
FLX> Z
("Z" instructs FILEX to initialize the new cassette and then
continue the copy operation.)
FLX> "'z
Now bring down the system, remove the MCR/FCP
mapped target disk on DK0: and reboot.

disk,

mount

the

have

been

Mount the first cassette.
>SET /UIC=[l,24]
>RUN $FLX
FLX> =CT0:*.*
FLX> "'z
Mount the second cassette.
>SET /UIC=[l,20]
>RUN $FLX
FLX> =CT0:*.*
FLX -- END OF VOLUME ON CASSETTE
CT0:[1,20]*.*
MOUNT NEW CASSETTE? {Y, Z (OUTPUT ONLY), OR CR)
Mount the third cassette.
FLX> Y
("Y" instructs FILEX to continue the copy operation.)
FLX>

Proceed to section
transferred.

5.4.2

when

all

the

files

Task Builder Instructions

The commands described below build the error logging tasks ERRLOG,
PSE, SYE and ERF.
The system disk must be the mapped or unmapped
object disk from the system generation distribution kit.
All the
necessary error logging files are on the system disk if the directions
in section 5.4.1 were successfully followed.
Any changes to the TKB command files must be made before
task builder.
For an unmapped system:
>SET /UIC=[l,20]
>RUN $LBR
LBR> ERL/CR:l4.:64.:64.=ERL.OBJ
LBR> "'z
>RUN $BIGTKB
TKB> @ERLBLD
TKB> @ERFBLD
TKB> @PSEBLD
TKB> @SYEBLD
TKB> "z
5-12

running

the

GENERATION PROCEDURES
For a mapped system:
>SET /UIC=[l,20]
>RUN $BIGTKB
TKB> @[l,24]PSEBLD
TKB> @[l,24]SYEBLD
>SET /UIC=[l,24]
>RUN $LBR
LBR> ERL/CR:l4.:64.:64.=ERL.OBJ
LBR> AZ
>RUN $BIGTKB
TKB> @ERLBLD
TKB> @ERFBLD
TKB> AZ
The following four task image files exist in directory
[1,50]
on an
unmapped system or
[1;54] on a mapped system when task building has
completed successfully:

5.5

ERL.TSK

ERF.TSK

PSE.TSK

SYE.TSK

TASK INSTALLATION

ERRLOG is the only task that needs to
error logging to function.
To install ERRLOG in an unmapped
privileged terminal:

installed

permanently

for

system,

type

the

following

system;

type

the

following

>INS [l,50]ERL
To install ERRLOG in
privileged terminal:

mapped

>INS [l,54]ERL
The other tasks may be executed by the
install/run/remove option of
the RUN command
("RUN $PSE",
for
example)
if the restrictions
explained below are met.
The file ERL.TSK contains the ERRLOG task image.
To ensure that error
logging runs efficiently,
ERL.TSK must be installed in a partition
that meets the following criteria:
•

All other tasks in the partition must be
must have a lower priority than ERRLOG.

checkpointable

and

•

ERRLOG should not run in the same partition as PSE and
unless the partition is large and system-controlled.

ERF

•

ERRLOG must not run in the same partition as FllACP since
uses its services.

When installing or running PSE in a system-controlled partition,
the
user
should append the /INC=xxx switch to the command line to
5-13

GENERATION PROCEDURES
increment the amount of space available to the task.
PSE needs
additional space at the rate of 10(decimal) words per device unit,
where device unit is each device that could cause an error to be
logged.
When running in a user-controlled
(task) partition, PSE
itself determines the space available and uses the amount it needs.

5-14

APPENDIX A
MODIFYING SYE AT TASK BUILD

The command file SYEBLD.CMD contains instructions to the task builder
to create the •.• SYE task
(see section 4.4.2). There are several
option statements in the command file that may be changed before task
build to modify the standard analyzer task SYE:
1.

The page width of and buffer size for output from the
terminal message processor to the terminals. These values
are defined by the following TKB option statements:
GBLDEF=PT$WTH:nnn
and
EXTSCT=TBUF:nnn
where nnn is octal and must be the same in
The default value is 110 (octal).

both

directives~

The value assigned to nnn does not affect task size.
2.

The page width and buffer size for the output from the error
processors.
These values are defined by the following TKB
option statements:
GBLDEF=PL$WTH:nnn
and
EXTSCT=OBUF:nnn
where nnn is octal and must be the same in
The default value is 120 (octal).

both

A user may want to increase the value of
advantage of a wide line printer, for example.

directives.
nnn

take

Note that the value of nnn affects the size of the task.
3.

The maximum number of devices that SYE can handle in summary
reports. The option statements related to the maximum number
are:
GBLDEF=MX$DEV:nn
and
EXTSCT=Vl:xxx

A-1

MODIFYING SYE AT TASK BUILD
where nn is the octal number representing the maximum number
of devices that SYE can handle, and xxx is an octal number
equal to 8.
(decimal) times the value of MX$DEV.
The default values
respectively.

are

(octal)

and

Each single increment to the maximum number
increases the SYE task size by four words.

500

(octal)

devices

Figure A-1 lists the contents of the command file SYEBLD.CMD.

A-2

MODIFYING SYE AT TASK BUILD

,rTHIS COMMAND FILE WILL BUILD THE ,,,SYE TASK FROM THE
rSYE~LD,CMD

,sYEBLD,ODL FILE rOR UN~APPED SYSTEMS

'[1 50]SYE/•CP/•MM, [1,30]SYE/•SP:SVEBLD/MP
,'
STACK:bU
1

ASG:TI11
TASK:,,,SYE
PAR•GEN:U00~01~0000

rTHIS DEFINES THE PAGE wIDTH FOR OUTPUT TO THE TERMINALS
rFROM THE TERMINAL MESSA.GE PROCESSOR • THIS HAS NO EFFECT ON THE
sOUTPUT OF THE ERROR DISPLAYS
JALL vALUtS •RE IN OCiAL

GBLDEF=PT$WTH1110

'rTHIS DEFINES

TH~

PAGE wIDTH FOR THE OUTPUT FROM THE ERROR

sPROCESSORS

'
IS THt DEFINITION Of THE PAGE LENGTH FOR THE OUTPUT FROM
';THIS
sTHE ERROR PROCESSORS
'JALL VALUES TYPED ARE OCTAL
GBLDEF=PLSLGH174
,1THIS IS THE MAXIMUM NUMBER Or DEVICES wHICH THE ANALYZER CAN HANDLE

1ALL VALUtS AR~ OCTAL
GBLDEF=PL$WTH:120

,suMMARIES OF SYSTEM LOGGED ERRORS,

J************** N 0 T E ****************
CHANGING THIS VALUE THE
'JWHEN
JLENGTH MUST BE ALSO CHANGED,
,1
,rALL VALUES ARE TYPED AS OCTAL
GBLDEf:MXSDEVlb2
,

N~XT

VALU£ OF THE SUMMARV TABLE

'THIS IS THE SIZE OF THE SUMMARY TABLE TO BE USED IN THE ANALYXER
JWHEN CHANGING THE NUMBER OF DEVICES WHICH THt ANALYZER CAN
sHANDLE SUMMARIES ON THIS VALUE ALSO MUST BE CHANGED,

J****************** N 0 T E ******************
J

JTO CHANGE THIS VALUE THE ~EW VALUE MUST BE EQUAL TO
rEIGHT C8,) TIMES THE VALUE OF "~XSDEV" ABOVE,

JALL VALUES TYPED ARE OCTAL

EXTSCT:V11620
II

Figure A-1

A-3

INDEX
Analysis task,
see SYE
Assembling,
ERF I 5-2
ERRLOG, 5-2
privileged tasks, 5-2

Formatting routines, 2-3
Files,
defaults for, 2-3, 2-5
error log, 2-3, 2-4, 2-5
ERROR.SYS, 2-4, 2-5
ERROR. TMP, 2-4, 2-5
ERR.TMP, 2-4, 2-5
SYEBLD.CMD, A-1, A-2, A-3

/BG switch, 3-5
/BR switch, 3-4
Generating,
error logging subsystem, 5-1
through 5-14
reports, 1-3, 2-5, 3-3, 3-4, 3-5
3-6, 4-1

/DE switch, 3-5, 4-6
Defaults,
command line, 3-2, 3-3, 3-4
system, 2-3
/DV switch, 3-5

/ED switch, 3-6
ERF, 1-2
assembling, 5-2
error messages, 3-12, 3-13
installing, 3-7, 5-5
running, 3-7
ERRLOG, 1-2, 2-3, 2-5
assembling, 5-2
error messages, 3-7, 3-8, 3-9
installing, 5-5
running, 3-1
Error logger,
see ERRLOG
Error logging,
files (see Files),
functions of, 1-1
purposes of, 1-1
reports, 1-3, 3-4, 4-1 through
4-8
tasks, 1-2, 2-3, 3-1 through
3-7
Error messages, 3-7 through 3-13
Errors,
detection of, 1-2
device, 1-2
interrupt timeout, 1-2
interrupt through unused vector,
1-2
types of, 1-2
ERR.TMP, 2-4, 2-5
ERROR.SYS, 2-4, 2-5
ERROR.TMP, 2-4, 2-5
Executive routines, 1-2, 2-1
formatting, 2-3
memory allocation, 2-3
queuing, 2-3

Installing,
ERF, 3-7, 5-13
ERRLOG, 5-13
PSE, 3-2, 5-13
SYE, 3-3, 5-13

LUN assignment,
changing, 2-5

Memory allocation routines, 2-3
Modifying SYE at task build, 3-12
A=l, A=2, A-3

Operating procedures, 3-1 through 3-7
Options,
SYE report, 3-4, 3-5, 3-6, 4-1
system generation, 5-1, 5-2

Pre-analyzer task,
see PSE
Procedures, operating, 3-1 through
3-7
PSE,
error messages, 3-9, 3-10, 3-11
incrementing space available
to, 3-2, 5-13, 5-14
installing, 3-2, 5-13
running, 3-1, 3-2

Queuing routine, 2-3

Index-1

INDEX (Cont.)
Reports,
generating, 1-3, 2-5, 3-3, 3-4,
3-5, 3-6, 4-1
individual error, 4-1 through 4-6
on device errors, 4-3, 4-4
on interrupt timeouts, 4-3, 4-4
4-6
on interrupts through unused
vectors, 4-1, 4-2
summary, 4-6, 4-7, 4-8
Running,
ERF, 3-7
ERRLOG, 3-1
PSE, 3-1, 3-2
SYE, 3-3

::il.il\J' 5-1
Shutdown task,
see ERF
/SU switch, 3-6
Summary reports, 4-6, 4-7, 4-8
Switches (SYE), 3-4, 3-5, 3-6
SYE,
error messages, 3-11, 3-12
installing, 3-3, 5-13
modifying at task build, 3-12,
A-1, A-2, A-3
report options, 3-4, 3-5, 3-6,
4-1
running, 3-3
switches, 3-4, 3-5, 3-6
SYEBLD.CMD, A-1, A-2, A-3
System generation options, 5-1,
5-2

Task,
building, 5-6
installation, 5-13
interaction, 2-3, 2-4, 2-5
operation, 3-1 through 3-7
Tasks, 1-2, 2-3
ERF, 1-2, 3-7
ERRLOG, 1-2, 2-3, 2-4, 3-1
error logging, 1-2, 2-3
PSE, 1-2, 2-5, 3-1, 3-2,
3-3, 4-1
SYE, 1-2, 2-5, 3-3, 3-4, 3-5,
3-6, 4-1

Index-2

RSX-llM Error Logging
Reference Manual
DEC-11-0MELA-A-D
READER'S COMMENTS

NOTE:

This form is for document comments only.
Problems
with software should be reported on a Software
Problem Repcrt (SPR) form.

Did you find errors in this manual?

If so, specify by page.

Did you find this manual understandable, usable, and well-organized?
Please make suggestions for improvement.

Is there sufficient documentation on associated system programs
required for use of the software described in this manual? If not,
what material is missing and where should it be placed?

Please indicate the type of user/reader that you most nearly represent.
[] Assembly language programmer
[]

Higher-level language programmer

[]

Occasional programmer (experienced)

[]

User with little programming experience

[]

Student programmer

[] Non-programmer interested in computer concepts and capabilities

CitY~------------------------~State~~~~~~-Zip Code~~----------

or
Country
If you require a written reply, please check here.

[]

-------------------------------------------------------------Fold llere------------------------------------------------------------

·----------------------------------------------- Do Not Tear - Fold llere and Staple -----------------------------------------------

FIRST CLASS
PERMIT NO. 33
MAYNARD, MASS.
BUSINESS REPLY MAIL
NO POSTAGE STAMP NECESSARY IF MAILED IN THE UNITED STATES

Postage will be paid by:

Software Communications

P. O. Box F
Maynard, Massachusetts

01754

digital equipment corporation

Printed in US.A.