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.
