Condition step

The condition step begins after the enablement step has completed and Language Environment determines that an exception in your application should be handled as a condition. In the simplest form of this step, Language Environment traverses the stack beginning with the stack frame for the routine in which the condition occurred and progresses towards earlier stack frames. Condition handlers are invoked at each intervening stack frame and given a chance to respond in any of the ways described in Responses to conditions. The condition step lasts until a condition handler requests a resume or until default condition handling occurs (condition went unhandled). Throughout the following discussion, refer to Figure 1.

Figure 1. Condition processing
Starting at the stack frame for the routine in which the condition occurs, Language Environment traverses the stack toward earlier stack frames. Condition handlers are invoked at each intervening stack frame and given a chance to respond.
  1. Language Environment condition handling begins at the most recently activated stack frame. This is the stack frame associated with the routine that incurred the condition. In Figure 1, this is A, or routine 4.
  2. If the debug tool is present, and the setting of the TEST runtime option indicates that it should be given control, it is invoked. See z/OS Language Environment Programming Reference for information about the TEST runtime option.
  3. If the debug tool is not invoked, or does not handle the condition, Language Environment traverses the stack, stack frame by stack frame, towards earlier stack frames. This is in the direction of arrow B in Figure 1. User-written condition handlers established using CEEHDLR, and then language-specific condition handlers present at each stack frame such as C/C++ signal handlers or PL/I ON-units, can all respond by percolating, promoting, or handling the condition (see Responses to conditions for a discussion of these actions).
  4. Condition handling is complete if one of the handlers requests the application to resume execution. If all stack frames have been visited, and no condition handler has requested a resume, the language of the routine in which the exception occurred can enforce default condition handling semantics.
  5. If the HLL of the routine that originated the condition does not issue a resume, what occurs next depends on whether there is a PL/I routine active on the stack.
    1. The condition is percolated if there is no currently active PL/I routine or if the condition is not one that PL/I promotes to the ERROR condition (see Promoting conditions to the PL/I ERROR condition for details). Language Environment default actions are then taken based on the severity of the unhandled condition, as indicated in Table 1.

      If the condition is of severity 2 or above, Language Environment promotes the condition to T_I_U (termination imminent due to an unhandled condition) and returns to routine 4 to redrive the stack (this occurs at points C and D in Figure 1). For more information about the termination imminent step and T_I_U, see Termination imminent step.

    2. If the condition is one that PL/I promotes to the PL/I ERROR condition (see Promoting conditions to the PL/I ERROR condition for details), the condition is promoted at the location represented as C in Figure 1, and another pass is made of the stack. The following takes place:
      • On the next pass of the stack (D), any ERROR ON-unit or user-written condition handler is invoked. If the ON-unit or user-written condition handler issues a resume, condition handling ends. Execution resumes where the resume cursor points.
      • If no ON-unit or user-written condition handler issues a resume, the ERROR condition is promoted (at E) to T_I_U. (See Processing the T_I_U condition for a discussion of T_I_U.)
      • A final pass of the stack is made, beginning in Routine 4 where the original condition occurred (F). Because T_I_U maps to the PL/I FINISH condition, both established PL/I FINISH ON-units and user-written condition handlers registered for T_I_U are invoked.
      • If no user-written or HLL condition handlers act on the condition, Language Environment begins thread termination activities in response to the unhandled condition (G). See Table 1 for the default actions that Language Environment takes for conditions of different severities.