Filter
Top Products
CHAPTER
6
FAULTS
.
This
chapter
describes
IP
faults,
exceptional
corrlitions
which
can
occur
as
the
IP
performs
functions.
In
general,
the
IP
fault
philosophy
follows
that
of
the
GOP:
the
processor
detects
and
contains
faults
so
they
do
not
affect
other
processes
or
processors
in
the
432
system.
The
response
to
a
fault,
i.e.
fault
handling,
is
not
predefined
and
may
be
tailored
through
software
to
the
needs
of
the
432
system
user.
The
IP's
dual
role
in
the
432
system
and
in
the
Peripheral
Subsystem
requires
that
the
strategy
for
handling
faults
is
somewhat
different
than
for
the
GOP.
6-1.
FAULT
REPORTING
When
a
fault
occurs,
the
IP
records
information
about
the
fault
in
a
fault
information
area.
Faults
are
distinguished
by
a
fault
code
and
an
operator
ID
recorded
in
the
fault
information
area.
The
fault
codes
are
specified
in
Appendix C. The
operator
IDs
are
specified
in
Appendix B. The
operator
ID
designates
the
IP
function
which was
executing
when
the
fault
was
encountered.
A
unique
operator
ID
corresponds
to
each
IP
function
code.
Note
that
the
values
for
the
function
codes
are
not
the
same
as
the
values
for
the
corresponding
operator
IDs.
When
the
IP
has
deposited
the
information
in
the
respective
fault
information
area
am
updated
the
function
state,
the
IP
interrupts
the
AP
to
inform
it
of
the
fault.
The
AP
may
check
the
function
state
field
of
the
function
request
facility
to
acquire
the
field
of
bits
which
contains
the
fault
level.
If
the
IP
has
faulted,
the
AP
examines
the
corresponding
fault
information
area
for
more
detail.
For
faults
which
occurred
during
the
execution
of
a
function
with
a
sequence
of
steps,
like
SEND
or
RECEIVE,
the
IP
records
the
execution
state
when
the
function
faulted.
This
information
allows
the
time
when
the
fault
occurred
to
be
specified
more
precisely.
Then,
software
which
handles
the
fault
can
respond
in
the
fOC)st
appropr
iate
manner. The
execution
state
information
is
necessary
for
software
completion
of
a
partially
executed
function.
6-1