top - download
⟦ec6e86abc⟧ Wang Wps File
Length: 12067 (0x2f23)
Types: Wang Wps File
Notes: INTERN MEDDELELSE NR. 79
Names: »0872A «
Derivation
└─⟦872f87e0f⟧ Bits:30006013 8" Wang WCS floppy, CR 0052A
└─ ⟦this⟧ »0872A «
WangText
7…05…7…07…6…09…6…0d……86…1
…02…
…02… …02…
…02…
…02… FH/810409…02……02…#
INTERN
MEDDELELSE
NR. 79
…02……02…CAMPS
To: JH[
Fm: KNN
cc: HKI, FH, OKH
S̲u̲b̲j̲e̲c̲t̲:̲ ̲E̲r̲r̲o̲r̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
Response due date: 24th April 1981
As error processing represents a critical item in relation
to the CAMPS program, we kindly ask you to generate
formal answers to the attached comments.
C̲R̲I̲T̲I̲Q̲U̲E̲ ̲O̲F̲ ̲E̲R̲R̲O̲R̲ ̲P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲
G̲E̲N̲E̲R̲A̲L̲ ̲C̲O̲M̲M̲E̲N̲T̲S̲
1 No description of user fix-up facilities
2 No description of reporting to responsible/parent/
creator process
3 No description of types of CCs and corresponding
actions
SD REQUIREMENT: Appendix A+B+C.
H̲A̲N̲D̲L̲I̲N̲G̲ ̲O̲F̲ ̲H̲W̲ ̲G̲E̲N̲E̲R̲A̲T̲E̲D̲ ̲E̲R̲R̲O̲R̲ ̲I̲N̲T̲E̲R̲R̲U̲P̲T̲S̲
It shall be possible for a user to take over the handling
of these interrupts. E.g. an on-line diagnostics program
will test the priviliged mode hardware check-out circuit.
SD REQUIREMENT: Appendix A9.
E̲R̲R̲O̲R̲ ̲R̲E̲P̲O̲R̲T̲I̲N̲G̲
G̲e̲n̲e̲r̲a̲l̲
DAMOS errors are reported in 4 ways:
1 To CESE:
It is not yet defined, which errors are reported
to CESE. This reporting is additional to 3+4.
2 To a responsible process:
- for handlers the FMS/THS or the creator
- for users the parent
- for FMS/TMS the parent
This reporting is additional to 3+4.
3 Via a 16 bit CC
4 A process which is retired/retires reports to the
parent.
A̲d̲ ̲1̲:̲
The error reporting to CESE may imply that an error
is reported, even if it is locally remedied. (E.g.
a handler detects an irrecoverable disk drive error,
but the FMS switches to a redundant disk drive.
REQUIREMENT: Delete this reporting facility.
A̲d̲ ̲2̲:̲
The responsible process for a handler will always be
the caller (FMS/THS). Therefore, the reporting to the
responsible process is additional to the normal return
code. This is superflous and may create synchronization
problems.
In CAMPS reporting for FMS to CESE and parent will
be identical.
However, reporting to the creator of an object, may
be useful.
SD REQUIREMENTS: Appendix A10 + B6.
A̲d̲ ̲3̲ ̲+̲ ̲4̲:̲
DAMOS was a built-in strategy (defined during system
coding) for handling of user process errors:
a) The user process receives a CC.
b) The user process is retired.
A user cannot avoid being notified (in case b). A parent
cannot inhibit a child from handling specific errortypes
(in case a). In CAMPS, semantic erors will be handled
according to b). Refer to appendix A for a definition
of a CC to type relation, which is defined by a application.
It is not clear, which errors there are handled by
which of the above schemes.
SD REQUIREMENTS: Appendix A3, 4, 5 + B1, 2, 3.
A̲d̲ ̲1̲ ̲+̲ ̲2̲ ̲+̲ ̲3̲ ̲+̲ ̲4̲:̲
It is unclear how the above reporting schemes coordinates.
E̲R̲R̲O̲R̲ ̲R̲E̲P̲O̲R̲T̲I̲N̲G̲
A̲d̲ ̲3̲.̲1̲.̲1̲.̲1̲ ̲i̲n̲ ̲P̲S̲P̲/̲0̲0̲2̲7̲:̲
- Who decides which errors are harmful?
E.g. in CAMPS, semantic errors are harmful, but
they are not reported.
- Who decides which errors are vital for maintenance?
This is application dependent.
REQUIREMENTS: Appendix A 1,2.
E̲R̲R̲O̲R̲ ̲I̲N̲F̲O̲R̲M̲A̲T̲I̲O̲N̲
The source of an error is not easy to predict. It may
be hardware or software stimulated. Therefore, the
error information shall identify:
- Sender of error report (RSI)
- CPU/PU
- Stimulator of the error: by program counter and
register contents
- time of day
- optionally a dump of a failed process shall be
performed
SD REQUIREMENTS: Appendix C
U̲S̲E̲R̲ ̲P̲R̲O̲C̲E̲S̲S̲ ̲F̲A̲C̲I̲L̲I̲T̲I̲E̲S̲
Errors are handled by a user in a cumbersome way:
E.g.:
READ ̲BYTES( , , CC)
IF CC 0
THEN
CASE CC OF
CC1:
BEGIN
ERROR FIX-UP ACTIONS, E.G. CALL RETIRE
END
CC2:
.
.
.
C̲o̲m̲m̲e̲n̲t̲s̲
The handling of a CC is to be done explicitly, and
if a user "forgets" to do so, an unpredictable situation
will arise (may imply violation of integrity of operation).
SD REQUIREMENTS: A1, 2, 3
E̲R̲R̲O̲R̲ ̲F̲I̲X̲-̲U̲P̲ ̲F̲O̲R̲ ̲T̲H̲E̲ ̲T̲O̲P̲-̲L̲E̲V̲E̲L̲ ̲P̲R̲O̲C̲E̲S̲S̲
It is not defined how DAMOS handles errors* in the
top level process.
The scheme is different from child process fix-up as
no parent exists.
* In the EP HW generated interrups are handled.
E̲R̲O̲R̲ ̲F̲I̲X̲-̲U̲P̲ ̲S̲U̲B̲S̲E̲Q̲U̲E̲N̲T̲ ̲T̲O̲ ̲A̲ ̲M̲U̲L̲T̲I̲-̲O̲B̲J̲E̲C̲T̲ ̲E̲R̲R̲O̲R̲ ̲(̲E̲.̲G̲.̲
̲I̲O̲ ̲B̲U̲S̲/̲L̲T̲U̲/̲L̲T̲U̲X̲)̲ ̲E̲R̲R̲O̲R̲.̲
It is not defined how these errors are handled.
Proposal: Notify user/parent
Notify creator
P̲A̲P̲E̲R̲-̲O̲U̲T̲
It is not defined how DAMOS reacts to paper-out.
H̲O̲W̲ ̲I̲S̲ ̲D̲I̲V̲I̲S̲I̲O̲N̲ ̲B̲Y̲ ̲Z̲E̲R̲O̲ ̲H̲A̲N̲D̲L̲E̲D̲?̲
H̲O̲W̲ ̲I̲S̲ ̲O̲V̲E̲R̲F̲L̲O̲W̲ ̲I̲N̲ ̲A̲D̲D̲/̲S̲U̲B̲ ̲H̲A̲N̲D̲L̲E̲D̲?̲
R̲E̲S̲O̲U̲R̲C̲E̲ ̲E̲R̲R̲O̲R̲S̲
The handling is application dependent.
Some resource errors shall imply a CC (e.g. in CAMPS
for paper out); some resource errors shall retire the
process (e.g. no IOCBs).
SD REQUIREMENTS: A1, 2, 3
P̲O̲S̲T̲ ̲M̲O̲R̲T̲E̲M̲ ̲M̲E̲M̲O̲R̲Y̲ ̲D̲U̲M̲P̲
1) The described post mortem dump only works, if the
PU is ordered shut down. In case of a non-ordered
shut down the PU ̲ERROR procedure will never be
called. At a subsequent "master clear" the MAP
contents is overwritten and the post mortem analysis
is of no value.
Proposal: The MAP micro processor, which functions
independent of RAM + CPU, could perform
a memory dump in all cases. However,
the MAP microprocessor is only invoked
in "maintenance-mode", where the PU
is disabled, and thus a memory dump
to a disk cannot be performed.
2) In PSP/29 whereto PSP/27 (in section 3.1.1.6 and
3.1.1.6.1) references a post mortem dump and analysis
facility, these are not described:
- memory cannot be dumped to disk as is a CAMPS
requirement
- no analysis exists. An analysis might print
out a specified process with a layout containing:.
- integer
- hexadecimal
- instruction mnemonics
- characterwise, or the like.
SD REQUIREMENTS: Hardware and software to be redesigned.
R̲E̲T̲I̲R̲E̲/̲R̲E̲S̲U̲M̲E̲
When a parent process resumes a child process, information
should be given to the child defining the actions taken
by the parent.
SD REQUIREMENTS: Appendix A8
2) It shall be possible to dump the memory segments
of a single failed process.
SD REQUIREMENT: Appendix C
T̲R̲A̲C̲E̲
(p. 16) why is Trace limited to CPU level 0? Do you
not want to debug DAMOS?
E̲R̲R̲O̲R̲ ̲R̲E̲P̲O̲R̲T̲I̲N̲G̲ ̲C̲O̲O̲R̲D̲I̲N̲A̲T̲I̲O̲N̲
An analysis of CR80D Hardware (incl. TDX and Channel
Unit) and System Software error conditions is required.
Outcome shall be:
a) A description of error reporting channels (which
modules involved).
b) A definition of error information delivered in
order to:
- facilitate manual maintenance (operator intervention)
- facilitate automatic fix-up
c) For each error condition define where in the system
(if any) automatic fix-up is implemented.
The SSD should at least provide this information assuming
hardware information is predefined.
DAMOS shall provide fix-up for DAMOS components where
possible (e.g. fix-up for FMS).
Where fix up is not implemented within the system software
recommendation for fix-up shall be given.
C̲E̲S̲E̲ ̲O̲V̲E̲R̲F̲L̲O̲W̲
Report to CESE may be impossible due to lack of resources.
Repeated error reports may not be feasable. Expand
analysis in previous section to identify for which
cases a repeated error shall be reported, and for which
not.
For example a device handler may only send a short
error notification, the full description given as a
result of call to Handler. This call could be used
to unlock for further report generation.
P̲A̲R̲I̲T̲Y̲ ̲E̲R̲R̲O̲R̲ ̲I̲N̲ ̲P̲U̲ ̲M̲E̲M̲O̲R̲Y̲
A parity error detected during execution of system
software implies a PU shut down.
However, parity errors are likely to be sporadic and
therefore, the instruction implying the error has to
be repeated.
SD REQUIREMENTS: Repeat operation
Describe information given, when a parity error is
detected e.g.
- memory location
- CPU
- memory location contents
P̲U̲ ̲S̲H̲U̲T̲ ̲D̲O̲W̲N̲
A PU is shut-down without any notification.
SD REQUIREMENTS: Issue an error message to the operator
position.
A̲ ̲ ̲P̲ ̲ ̲P̲ ̲ ̲E̲ ̲ ̲N̲ ̲ ̲D̲ ̲ ̲I̲ ̲ ̲X̲ ̲ ̲ ̲A̲
C̲A̲M̲P̲S̲ ̲U̲S̲E̲R̲ ̲E̲R̲R̲O̲R̲ ̲H̲A̲N̲D̲L̲I̲N̲G̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
1) Errors (CC) shall be divided into 16 types.
2) A table shall exist, which defines a CC to type
relation.
3) It shall be possible for a user to mask certain
error types and take-over the error handling via
an application procedure automatically invoked,
when the error occurs.
4) It shall be possible to inhibit a user from specifying
certain error types in the mark.
5) Errors not handled locally are sent to the parent
process.
6) The process handling the error shall have access
to all completion information.
7) A process, for which the parent takes over the
error handling, is retired.
8) It shall be possible to restart a retired process
and give it information about the fix-up performed.
This may be implemented by letting the retired
process retire in an await info element statement.
9) It shall be possible for a user to take over the
handling of CPU firmware generated error interrupts.
E.g. an on-line diagnostics program will test the
privileged mode hardware check-out circuit.
10) For certain critical errors an error report shall
be sent to a responssible process (e.g. the creator
of an object).
A̲ ̲ ̲P̲ ̲ ̲P̲ ̲ ̲E̲ ̲ ̲N̲ ̲ ̲D̲ ̲ ̲I̲ ̲ ̲X̲ ̲ ̲ ̲B̲
C̲A̲M̲P̲S̲ ̲U̲S̲E̲R̲ ̲E̲R̲R̲O̲R̲H̲A̲N̲D̲L̲I̲N̲G̲ ̲I̲M̲P̲L̲E̲M̲E̲N̲T̲A̲T̲I̲O̲N̲
1) A user specified error handling procedure shall
be specified in system procedure calls.
2) The errorhandling procedue shall have the following
- call parameters
- mask (16 bits defining the error types
to be handled)
- return parameters
- CC
- type
- detailed error information
3) It is the responsibility of the system procedure
to invoke either the parent or the user error handling
procedure.
4) A report-error procedure shall be available for
a user, which subsequent to an error fix-up, will
report the fix-up.
5) A user process shall be able to retire at its own
will.
6) For certain error types a report shall be sent
to a responsible process.
These error types are defined at system generation.
A̲ ̲ ̲P̲ ̲ ̲P̲ ̲ ̲E̲ ̲ ̲N̲ ̲ ̲D̲ ̲ ̲I̲ ̲ ̲X̲ ̲ ̲ ̲C̲
E̲R̲R̲O̲R̲ ̲R̲E̲P̲O̲R̲T̲ ̲I̲N̲F̲O̲R̲M̲A̲T̲I̲O̲N̲
An error report shall include the following information:
- time of day
- identification of device/program detecting the
error
- detailed device status e.g.
- erroneous device
- detailed device status
- identification of current PU and CPU
- an identification of which statement provoked the
error (e.g. line no or program counter)
- CC
- error type
- register contents at point of failure
- optionally the segments of a failed process shall
be dumped on a disk file.
