REXX SIGNAL ON ERROR Deployment Log Triage Failure Policy

Recommendation

For a deployment‑log triage script, the safest default is to continue after logging each trapped error. Aborting on the first error provides immediate notification but discards later diagnostic information, which defeats the purpose of a comprehensive failure summary.

Why Continue-After-Log Is Preferred

• Multiple independent failures can appear in a single log; stopping early hides cascading or unrelated issues.
• Each runtime error raises the ERROR condition, allowing the handler to record the line number (SIGL) and message (ERRORTEXT(RC)).
• A single summary report lets operators prioritize fixes without re‑executing the script.

Safe Condition Functions

The following built‑in functions are part of the ANSI/REXX standard and behave consistently across Regina, IBM z/OS REXX, and Open Object REXX:

• RC – set to a non‑zero value indicating an error; in most standard REXX interpreters this value is 4.
• SIGL – line number where the error occurred.
• ERRORTEXT(RC) – returns the interpreter’s message for the trapped error code.
• ERRORLINE() – returns the source line text (available in Regina and ooRexx; on IBM mainframe use SOURCELINE(SIGL)).

Caution: RC and SIGL semantics can vary between interpreters; always verify with a minimal test script on the target platform.

Minimum Filesystem Privileges

• Read access to every deployment log file and to each directory in its path (r and x permissions).
• Write/Create access to the diagnostic report destination directory (w on the directory; x if the file may not yet exist).

No elevated privileges are required unless logs reside in protected system locations.

Critical Gap

SIGNAL ON ERROR only catches REXX runtime errors. Failures from external commands invoked via ADDRESS COMMAND or system() do not raise the ERROR condition. You must check RC immediately after each external call and handle non‑zero results explicitly.

Verification Steps Before Deployment

1. Run a test script that forces a runtime error (e.g., SIGNAL ON ERROR; x = 1/0) and confirm RC=4 and SIGL point to the offending line.
2. Attempt to open each deployment log for reading and the report file for writing using STREAM() or LINEIN()/LINEOUT() to validate privileges.
3. Invoke a known‑failing external command (e.g., ADDRESS COMMAND 'false') and verify the ERROR handler is not entered; instead, check RC after the call.