Limits: Graceful Cancellation and Timeout Support in Rexx's SIGNAL ON HALT

Limits of SIGNAL ON HALT and Resumption

The SIGNAL ON HALT clause allows a Rexx program to trap asynchronous interrupts (such as Ctrl+C). However, the primary limit is that resumption is not guaranteed to be immediate during blocking operations. Because Rexx often delegates ADDRESS calls to the host operating system, the interpreter may not regain control to execute the trap handler until the external process returns control to the interpreter.

Implementation Variations

Behavior varies across the three major interpreter families:

• Regina Rexx: Generally executes the handler and resumes at the instruction following the interrupted one. It is often more consistent in handling multiple interrupts.
• ooRexx: Follows similar resumption logic, but the ability to interrupt a blocking host call depends heavily on the underlying OS signal handling (e.g., how the JVM or C runtime handles SIGINT).
• Classic/Mainframe Rexx: Behavior is tied to the specific environment (e.g., TSO/E or VM), where interrupts may terminate the task entirely regardless of the trap if the system-level interrupt takes precedence.

Enforcing Timeouts on Blocking ADDRESS Calls

There is no portable, built-in Rexx keyword for timeouts. To enforce a timeout without using non-portable extensions, you must shift the timeout logic from the Rexx interpreter to the host command itself.

Instead of calling a command directly, wrap the command in a host-level utility that supports timeouts. For example:

• Linux/Unix: Use the timeout command (e.g., ADDRESS CMD "timeout 10s my_script.sh").
• Windows: Use a wrapper script or a PowerShell command with the -TimeoutSec parameter.

By handling the timeout at the OS level, the host command returns a specific exit code to Rexx, which can then be evaluated using RC to trigger a graceful failure.

Best Practices for Resource Cleanup

To ensure external subprocesses or files are cleaned up when a HALT trap is invoked, follow these patterns:

1. Centralized Cleanup Routine: Place all cleanup logic (closing files, deleting temp files, killing child PIDs) in a single labeled routine.
2. The HALT Handler: Use the SIGNAL ON HALT handler to call this cleanup routine and then explicitly EXIT or LEAVE to prevent the program from resuming in an unstable state.
3. Tracking State: Maintain a global list or stem variable of active resources. The cleanup routine should iterate through this list to ensure no orphaned processes remain.

Verification: To verify behavior in your specific environment, run a script with a long ADDRESS sleep command (e.g., ADDRESS CMD "sleep 30") and trigger a HALT signal. If the handler does not execute until the sleep finishes, your environment cannot interrupt blocking host calls.