REXX EXIT statement exit‑code propagation inconsistency after schema change rollback

Direct answer

IBM z/OS TSO/E REXX: EXIT 5 sets the exec return code to 5. The caller reads it as the TSO/E condition code (RETURN CODE) immediately after the exec finishes. z/OS condition codes are conventionally 0‑4095, so 5 is safe; values outside that range may be truncated.

OpenRexx (Unix‑like and Windows): EXIT 5 terminates the process with exit status 5. The status reaches the caller only if the caller explicitly checks the process exit code (e.g., $? on Unix, %ERRORLEVEL% on Windows). When OpenRexx is invoked indirectly—through a wrapper script, scheduler, or embedding API—the intermediate layer must forward that status; there is no single OpenRexx configuration flag guaranteed to force propagation on all hosts.

OS/2 REXX: EXIT 5 sets the CMD/4OS2 ERRORLEVEL to 5. Batch files can test it with IF ERRORLEVEL 5 or %ERRORLEVEL%.

Likely explanation vs. confirmed facts

• Confirmed: Each interpreter uses a different host mechanism (condition code, process exit status, ERRORLEVEL). The REXX language spec only says EXIT may take a numeric argument; it does not mandate a uniform propagation model.
• Likely: The inconsistency you see after a schema‑change rollback is caused by the indirect invocation layer (e.g., a CI job, a wrapper script, or an embedding host) discarding or not forwarding the child process status.
• Uncertain / needs verification: Whether a specific OpenRexx build‑time or run‑time option (such as -e, --exit-code, or an API flag) can guarantee propagation across *all* indirect paths. Current documentation does not confirm a universal setting.

Steps to verify on your target platforms

1. Create a minimal script test_exit.rex containing only:

   exit 5

2. z/OS: Run under TSO/E and immediately issue TSO SHOW RETURNCODE or check the job step condition code. Expect 5.
3. OpenRexx (Unix):

   rexx test_exit.rex
   echo $?

   Expect 5.
4. OpenRexx (Windows):

   rexx test_exit.rex
   echo %ERRORLEVEL%

   Expect 5.
5. OS/2: Run from a CMD prompt and then echo %ERRORLEVEL%. Expect 5.
6. Repeat each test *through the actual indirect invocation* you use for rollback (e.g., a wrapper script, Jenkins step, or embedding call). Capture the status the same way. If the status differs, the loss occurs in that layer, not in the REXX interpreter.
7. Optional boundary test: replace exit 5 with exit 4095 and exit 5000 to see whether the host truncates or rejects out‑of‑range values.

Configuration changes for OpenRexx (if any)

As of the latest publicly documented releases, OpenRexx does not expose a single switch that forces exit‑code forwarding through arbitrary wrappers. The reliable approach is to ensure the wrapper itself propagates $? / %ERRORLEVEL% (e.g., exit $? in a shell wrapper, or SystemExit(exitCode) in an embedding host). If you are using a specific scheduler or API, consult its documentation for “preserve child exit code” options.

One missing diagnostic detail

What is the exact indirect invocation method you use for OpenRexx in the rollback pipeline (e.g., a shell wrapper script, a CI/CD step type, an embedding API call)? Knowing this lets me confirm whether a configuration flag exists for that specific path or whether the wrapper must be modified.