0 |
The run-time system uses the signal
sig if it needs to.
By default, the run-time system sets up signal handlers
for all signals whose operating system default action would cause termination.
The run-time system can thus catch these signals and tidy up (for example,
close any open files to prevent file corruption) before exiting. |
1 |
The run-time system uses the signal
sig if, and only if, a handler was not already
posted for this signal.
This is useful if the third-party software is invoked
before your COBOL system and sets up a handler for signal
sig. If this tunable is not set for this signal, the
run-time system overwrites the third-party software's handler with its own;
this leads to unpredictable behavior, such as run-time system error
115 ("Unexpected
signal") being produced.
If a handler was posted, the run-time system will not
post any handlers for this signal and so any run-time system functionality
which relies on this signal will not work. |
2 |
The run-time system never uses the signal
sig.
This is only of use if the third-party software is
invoked after the run-time system and sets up a handler for signal
sig. Use of this setting is strongly discouraged for
any signal whose operating system default action is to cause termination; if
this signal is received between the run-time system being invoked and the
third-party software setting up its handler, the default action of the
operating system occurs, and the process exits without the run-time system
being able to tidy up. This could lead to problems such as file corruption.
Any run-time system functionality which relies on this
signal will not work. |