Does a Rexx SIGNAL ON trap stay armed after the handler runs?

Answer

In the three mainstream Rexx interpreters—classic IBM Rexx, ooRexx, and Regina—a SIGNAL ON trap remains active after its handler routine finishes. The trap is not cleared automatically; it will fire again on the next occurrence of the same condition until a SIGNAL OFF or a new SIGNAL ON for that condition is issued. The interpreter keeps the trap registration separate from the condition flag that is cleared when the condition is raised.

How the interpreters behave

• IBM Rexx (ANSI X3.274‑1996) – Trap persistence is guaranteed. A SIGNAL ON issued inside an active handler simply replaces the existing definition; the new definition will be used for future occurrences.
• ooRexx – Identical to IBM Rexx; traps are persistent and re‑definition inside a handler behaves the same way.
• Regina – Follows the same model. Some older or custom Regina builds may treat an inner SIGNAL ON as a redefinition rather than a nested trap, but the trap remains active until explicitly turned off.

Why this matters for retry loops

Because the trap stays armed, a retry loop can safely issue a single SIGNAL ON before the loop starts. Each failure inside the loop will invoke the handler without needing to re‑arm the trap on every iteration.

Verification steps (safe, scoped commands)

1. Create a test script that registers a trap:

   /* test.trap.rex */
   SIGNAL ON ERROR HANDLER errorHandler
   
   DO i = 1 TO 3
     /* Force an ERROR condition */
     ERROR "Iteration &i"
   END
   
   errorHandler:
     SAY "Caught ERROR in handler, i = &i"
     RETURN
   

2. Run the script under each interpreter:

   rexx test.trap.rex
   ooRexx test.trap.rex
   regina test.trap.rex
   

3. Check that the handler prints three times without re‑issuing SIGNAL ON.
4. To test redefinition, add a second SIGNAL ON ERROR inside errorHandler that prints a different message. Verify that the outer trap remains active and the new definition takes effect for subsequent errors.
5. Confirm the interpreter’s version string (e.g., REXXVER in IBM Rexx) to ensure it implements ANSI X3.274‑1996.

Potential pitfalls to watch for

• If the handler itself raises the same condition, the trap may be re‑entered recursively. Guard against infinite recursion by clearing the condition or using a flag.
• Some very old or non‑standard Rexx builds may deviate from this behavior; test explicitly if you are using a custom interpreter.

Missing diagnostic detail (for clarification)

Which Rexx interpreter and version are you using? Knowing the exact build can help confirm that the persistent trap behavior applies to your environment.