Multitasking Considerations
Chapter 7: Error and Conditi()n Handling
This chapter deals with the method used to implement ~~g£~t!Q~_t!mg error handling.
All errors detected at execution time are PL/I language follows. rhe implementation problems these facilities raise and the method used to solve them are then
described. A separate section is devoted to the CHECK condition because this raises special problems. The chapter is completed by a brief discussion of the error message modules, the modules used to implement the PLIDUMP facility, and the handling of the compiler FLOW option.
Error detection during compilation is not covered in this chapter. Nor is any advice given on how to use PL/I error handling facilities. Advice on debugging with dumps is given in chapter 12. are used to describe certain implementation features and concepts. The terms are listed below.
~stablished: This term is used to describe on-units and, sometimes, ON statements.
The on-unit or statement is said to be
"established", if the action specified in the on-unit or ON-statement will be taken should the specified condition arise. Thus an on-unit becomes established when the ON certain PL/I conditions (SIZE, CONVERSION, etc.). A condition is enabled when the occurrence of the condition will result in the execution of an on-unit or standard action. A condition is disabled when the occurrence of the condition will,
apparently, be ignored.
QY~!!~igg_~nd Un~~lifigd Condit!Q~~:
Qualified conditions are those conditions, such as ENDPAGE, that need to be qualified by a file or other name. Unqualified conditions are those that do not need qualification. Figure 7.3 shows which conditions are qualified and which are unqualified.
~!Qg~m_£h~£!_~nQ_§Q!t~~!~_!n~!!~t~:
Certain PL/I conditions are detected automatically by the computing system.
Others have to be detectep by special checking code either in library modules or in the compiled program. Interrupts
detected by the system are referred to as
E!Qg~_£b~£~. Interrupts detected by special checking code are referred to as
2.Q!!::~fg::.9~£:!:gg or softwafg_i!!t~!gE~§'·
A list of program check interrupts and their associated PL/I conditions is given in figure 7.2.
These terms program check and software interrupts are used_for convenience in this publication and are not accepted terms in the PL/I language. Figure 7.3 shows which interrupts are system detected and which are software detected.
St~!::ic ~ng_QY!12mic_Qg2£g~g§~£y: Static and dynamic descendency are terms used to
define the scope of PL/I features. On-units are g~~mically de~nggn~. That is, they are inherited from the calling
procedure in all circumstances. Condition enablement is 2~~!::i£~!!y_de~£gnggnt. That is, i t is inherited from the containing block in the source program. Static descendency can be determined during
compilation. Dynamic descendency cannot be known until execution. See figure 7.4.
Normal Return: Normal return is return
from-a-Cilled
block by means of reaching the END or RETURN statement rather than because of a GOTO out of the block. In an error-handling context, normal return is taken to mean normal return from the§~~ndarg_Syst§ffi-~£tiQn~ Standard system
Fixed-point overflow I FIXEDOVERFLOW/SIZE Fixed-point divide I ZERODIVIDE/SIZE Decimal overflow I FIXEDOVERFLOW/SIZE Exponent overflow I OVERFLOW
Exponent underflow I UNDERFLOW Floating-point dividel ZERODIVIDE
L---J
Figure 7.2. ~achine interrupts associated with PL/I conditions
.. ....
. Background to Error Handling
The operating system offers certain error-handling facilities. These can be summarized as follows:
Various situations can cause an machine macro instruction. Alternatively, the programmer can accept the default action of
greatly extended facilities. The number of situations causing interrupts is
considerably larger and some, such as ENDFILE, can be used to control normal program flow rather than to handle errors.
The use of on-units allows the programmer to obtain control after any interrupt.
Alternatively he can accept standard system action. The programmer also has the choice figure 7.2>. ether conditions however belong only to PL/I.
The majority of PL/I conditions are caused by errors in program logic or the data supplied. Some, however, are not connected with errors. These are conditions such as ENDFILE, which occur at
unpredictable times and consequently cannot easily be anticipated by code in the source program.
Conditions that are most probably caused by programming errors are known as err2!
£Qngi~i2n§. Figure 7.3 shows which conditions are error conditions. The
standard system action for these conditions is to put out a message and raise the ERROR condition, and certain software detected conditions, such as taking the square root of a real negative number, also raise the ERROR condition.
The ERROR condition consequently gives the programmer blanket coverage of all program errors. The ERROR condition differs from other conditions in that a diagnostic message is always generated regardless of whether an ERROR unit exists. If an on-unit exists, the message is generated before on-unit action is taken.
A further facility offered by PL/I is the availability of condition built-in functions and pseudo-variables. These allow the programmer to inspect various condition enablement. Condition enablement is statically descendent and can be decided during compilation. On-units, however, are dynamically descendent and the
establishment or otherwise of on-units can only be decided during execution. (See
"Terminology" above.>
r---'---,
Name of IQual-IDescription IRecognized by I Default I Program I
condition lifiedl I I l-merIERROR**
I I I I IControl Condition
CONVERSION no
FIXEDOVERFLOW no
SIZE no
OVERFLOW no
UNDERFLOW no
l ZERODIVIDE no
I I
Attempt to ICode in relevant enabled convert invalid Ilibrary modules
character stringl
Overflow of a I I System enabled fixed point I
value I
Attempt to I Compiler-generated disabled assign too large checking code, or
a value hardware Overflow of a system floating-point
value
Exponent becomes System smaller than
permitted minimum
Attempt to System divide by zero
enabled
enabled
I enabled I
yes yes
yes yes
yes yes
yes yes
yes no
y'es yes
---~---~---~---.---~---I I I I
I I
ICode in relevant Jenabled Ilibrary modules
ENDFILE yes lEnd of file I reached ENDPAGE
TRANSMIT UNDEFINEDFILE KEY
NAME
yes
yes
I I
lEnd of a page onlCode in relevant la print file
I reached I Transmission
error on a file
Ilibrary modules I I
ICode in library I modules
yes Error in openinglcode in relevant I
file Ilibrary modules
yes Invalid key I ICode in relevant Ilibrary modules yes unrecognizable I Icode in relevant
data-directed Ilibrary modules
input I
I
enabled
enabled enabled enabled enabled
RECORD yes Incorrect size ICode in relevant I enabled
I record Ilibrary modules I
L---______________________________________________________ _
Figure 7.3. (Part 1 of 2). PL/I conditions
no yes
no nc
no yes
no yes
no yes
IIO no
no yes
----~---J
Chapter 7: Error and Condition Handling 89
r---,
Array subscript compiler-generated disabled outside declared checking code
bounds
yes/ Value assigned Compiler-generated I disabled no to identifier or checking code, or I
to I Relevant library
I modules I
L---___________________________________________
erro.r conditions.---J
I I Figure 7.3. (Part 2 of 2). PL/I conditions(SIZE):B:PROC;
ON ERROR SNAP;
•
•
•
CALL C;
CALL D;
D:PROC; E:PROC;
•
•
•
CALL E;
Static descendency: the enablement prefix (SIZE): in procedure B is inherited only by the contained procedure C, regardless of which procedure calls which.
Dynamic descendency: the on-unit ON ERROR SNAP; is inherited by any procedure called by B and any
subsequently called procedures. Thus, if B calls D, which calls E, the on-unit is established in procedure E.
Figure 7.4. static and dynamic descendency
Chapter 7: Error and Condition Handling 91
UNQUALIFIED CONDITIONS
1. A flag at the head of the DSA indicates that static ONCBs exist for that block.
2. the block and current enable cells indicate which of those conditions that are under programmer control are enabled at any given point in the program.
Each such condition is represented by a single bit in each cell.
3. There is an on-cell for every ON-statement in the block. Each on-cell consists of a onll-byte code identifying the condition, e.g., X'OA' (SUBSCRIPTRANGE).
If the Silme condition appears more than once, previous on-cells are set to zero.
4. Static ONCBs are held contiguously in static storage, in the same order as the corresponding on-cells. They contain a code byte and flags that indicate such things as: whether SYSTEM was specified, whether SNAP was specified, whether the on-unit consists of a single GOTO statement, whether it is a null on-unit, etc. If there is an on-unit, its address is given in the second byte. (For GOTO-only on-units, the offset of the address of the label variable is given.)
L . -_ _ _
Enable cells
On-cells DSA
Dynamic 1 - - - - , - - - 1 ONCS
Dynamic 1 - - - , - - - 1 ONCB
Dynamic J . -ONCB
J
QUALIFIED CONDITIONS
1. A flag at the head of the DSA indicates that dynamic ONCBs exist.
2. Dynamic ONCBs are set up during execution of each block in which qualified condition ON-statements occur. The last two words of a dynamic ONCB contain the same type of information as static ONCBs (described above, under 'Unqualified Conditions')' but use additional flags to indicate whether the condition is enabled and whether it is established. The second word contains qualifying information, such as the address of the FCB (for conditions such as ENDFI LE, RECORD, TRANSMIT, KEY, etc.), or address of a symbol table (for ON CHECK on-units).
3. Dynamic ON CBs are chained together, the most recent being addressed from a fixed offset in the DSA. The last dynamic ONCB in the chain contains zero in its backchain field.
LWS
1st level
2nd level
B~~ ONCA
Condition built-in ONCA
function information
Static storage
1st static ONCB
2nd static ONCS
/ - - - - ' - - - 1 Jrd static ONCB
Figure 7.5. The major fields used in error handling