This page discusses how a Multics program designed as a command or active function reports errors to a user. It also describes how an exec_com script might capture an error occurring in a command or active function, and take action depending upon nature of the error.
To get control when an error is detected by the command processor, or by some other command or active function called by your exec_com, you will need to understand:
How errors are reported by command programs.
How errors are reported by active functions.
In both cases, an on-unit established to handle the signaled condition may obtain information from the error_info structure to further diagnose the error. Action flags in the error_info structure permit an on-unit to tell com_err_ or active_fnc_err_ whether the on-unit receiving the error has displayed the error message.
See the MPM Subroutines (AG93-05a) manual for a description of the com_err_ and active_fnc_err_ subroutines. The write-up of active_fnc_err_ describes its signalling of the active_function_error condition, and gives some insight into how its sets up the error_info data and its control flags. Unfortunately, the same type of information is missing from the com_err_ subroutine description in that same manual.
See the MPM Reference Guide (AG91-04) starting at page 7-42 for a discussion of the active_function_error and command_error conditions that are signalled.
See MPM Commands and Active Functions (AG92-06) page 1-6 for a brief introduction on how commands and active functions report errors.
For further details, see the source for the com_err_.pl1 subroutine and its include files. This subroutine contains both com_err_ and active_fnc_err_ entry points. The following Multics command opens source for these segments in the emacs editor.
emacs [lpn com_err_.pl1 condition_info_header.incl.pl1 com_af_error_info.incl.pl1]
Users typing Multics commands must usually respond manually to errors reported by a command or active function (AF). They have no opportunity to pre-establish an on-unit to capture signals reported by such programs. Instead, initialize_process_ sets up default_error_handler_$wall in the earliest stack frame on the ring-4 stack. This on-unit provides default actions for expected conditions like command_error and active_function_error.
An exec_com can establish on-units to catch and print errors arising from command lines in the exec_com script. That on-unit can decide how to respond to those errors. For example, the exec_com can set variables indicating to its on-unit what type of handling would be appropriate for each type of error. Or it could selectively establish and revert its on-units for the command_error and active_function_error conditions as needed, so that errors are trapped only at certain critical points in the exec_com.
It is not easy within an exec_com to access the error_info data structure, set flags, etc. We can provide more advice on how this might be done if you decide that you want to pursue this signaled-condition approach.
Examine your exec_com to decide:
If actions would be taken only if special circumstances are true for a particular condition, describe also what those special circumstances would be. This will tell you what situations you want your on-units to detect, and perhaps how those circumstances may be detected.
If you have questions, you'll have enough data to present them in a way that will allow others to respond with ideas or approaches. By assembling this information, you'll learn enough about handling these conditions to better understand what is required, what can be implemented in an exec_com, what special approaches may be needed, etc. And you'll better understand any responses others may give for your questions.
Multics condition handling mechanisms are very powerful. Some people find them confusing because they involve detecting and handling events outside the normal flow of exec_com execution. When a condition occurs, the on-unit established to handle the condition pushes its own stack frame; but it still has access to data in its establishing exec_com.
An on-unit can only take one of three different actions to deal with a signaled condition.
When designing your error handling strategy, consider which of these alternatives you want to use when the on-unit is invoked.
Here is an example of a condition-handling exec_com (named condition.ec) which shows simple ways for handling the command_error signal.
&version 2
&trace &command &expanded
&goto DO_&ec_name
&label DO_condition
&- command_error
date_time foobar
&on command_error &begin
&goto condition_skip_1
&end
date_time foobar
&label condition_skip_1
&on command_error &begin
call cv_condition_$display condition.ec command_error
&exit &continue
&end
date_time foobar
&label condition_skip_2
&on command_error &begin
call cv_condition_$message -out -id message -dcl "char(600) var"
&+ -out -id condition_name -dcl "char(32) var"
&goto condition_skip_3
&end
date_time foobar
&label condition_skip_3
&quit
If you run this exec_com, you should see the following outputs. Can you explain where each line comes from?
ec condition
date_time foobar
date_time: An unknown word was found in the time string.
Date/Time args were: foobar
date_time foobar
date_time foobar
date_time: An unknown word was found in the time string.
Date/Time args were: foobar
date_time foobar
-- Return from: cv_condition_$message -------
message
condition_name command_error
r 13:40 0.161 2 level 2