HLL condition handling conventions

The HLL condition handling models basically fall into two categories: the stack frame-based model (PL/I), and the Global Error Table (GET) model (FORTRAN). To ensure a consistent view of condition handling in a multi-language thread that can involve both models, cooperation is required among the HLL condition handlers. The conventions for the HLL condition handling are:

• A stack frame is defined as a register save area that is back chained in the logical invocation stack.
• All HLL condition handlers must percolate all unknown conditions. An unknown condition is one for which the HLL has no defined action.
• When an HLL condition handler is called for enablement, unknown conditions must be enabled.
• All (enabled) conditions of severity 0 or 1 must permit a resume at the next sequential instruction without requiring any fix-up. If needed, any critical fix-up can be performed at enablement by the member deciding that the condition was enabled.
• When the action for a given condition is "ignore", the condition is considered to be disabled and the HLL condition handler must return not enabled when it is called for enablement.
• Some hardware conditions can be detected through software prior to raising the hardware condition. For example, the software can check for the ZeroDivide condition by checking for a zero divisor. If a condition is defined to be enabled by the HLL, and software detects a potential hardware condition, then the equivalent Language Environment condition must be signaled using CEESGL.
• Despite the above, statement-oriented language constructs are most appropriately handled directly in the HLL. Any corresponding condition is defined to be disabled. For example, the ON SIZE clause of a COBOL DIVIDE verb (which includes the logical equivalent of the ZeroDivide condition) can be handled by COBOL without ever raising a condition.
• For HLLs that employ the GET model, some conventions must be followed so that in a multi-language application that contains both the GET model HLL and the stack frame based model HLL the two models can work in concert. These conventions are:
  • For enabled conditions, the actions defined in the GET model are divided into two groups:
    1. Fix-up and resume
    2. Other than fix-up and resume

    If the default action is fix-up and resume, then that action must be taken at the owning stack frame.

  • If a user explicitly alters the action that needs to be taken for a particular condition within the GET (for example, registering his own handler to field the condition instead of taking the default action), the user-specified action must be honored.

    If the user changes the number of messages that are displayed for a particular condition, then the system action is still enforced at the zeroth stack frame.

  • If the condition is presented to a stack frame other than the owning stack frame (implying that the condition occurred in a non-GET language) or if the default action is something other than fix-up and resume, then the HLL condition handler must percolate the condition. Specifically, any existing GET actions that specify termination must be changed to percolation. These rules allow current semantics to be followed, but also permit inter-language cooperation.
  • If the HLL condition handler for the GET model is called for the zeroth stack frame, the "true" system action must be enforced at this time.
• If a HLL condition handling routine needs to permit nested conditions, and thus would be recursively entered, they must set the state variable in the CIB to cib_state_recursion.
• Those HLLs that employ a GET must provide a mechanism to allow a condition to be percolated. Users must be able to specify the percolation action.