Designing Rexx Automation Scripts Around Dynamic Typing and Variable Scope

Rexx treats every value as a variable-length string and lets subroutines share variables without explicit parameter lists. Those two decisions make it excellent for glueing together system output — and dangerous once a script grows past a few hundred lines. This note lays out the requirements where that trade-off works, the smallest design that stays safe, and the failure modes that should push you toward stricter structure.

Requirements Rexx's model actually fits

Rexx was built for environments where inputs are heterogeneous text: command output, log lines, console messages, CMS or TSO data streams. The string-everything model means you never write casting logic to compare a PID read from a pipe against a threshold — if pid > 9000 then just works, because Rexx converts strings to numbers at the point of arithmetic, not at assignment.

The design fits when your script is:

• Primarily a pipeline: read text, tokenize, decide, issue a command.
• Short-lived, with state that lives for one invocation.
• Maintained by someone who reads it top to bottom, not as a library.

It stops fitting when multiple scripts call each other as a framework, or when a wrong numeric conversion would trigger a destructive action (deleting datasets, stopping jobs).

The smallest suitable design

For a single automation script, the minimal safe structure is: a PARSE ARG header for inputs, PROCEDURE on every internal subroutine, and one explicitly documented shared stem (compound variable) for cross-routine state.

/* logscan.rexx — summarize error counts per job */
parse arg logfile threshold
if threshold = '' then threshold = 100

count. = 0                 /* shared stem, initialized */
call scan logfile

do job over exposed_jobs
  if count.job > threshold then
    say job 'exceeded threshold:' count.job
end
exit 0

scan: procedure expose count.
  parse arg fname
  do while lines(fname) > 0
    line = linein(fname)
    parse var line . 'JOB' jobid 'RC=' rc .
    if rc > 0 then count.jobid = count.jobid + 1
  end
  call lineout fname
return

The key decision is PROCEDURE EXPOSE count.. Without PROCEDURE, a Rexx subroutine sees every caller variable — convenient, but it means a typo inside scan silently creates or overwrites a caller variable. With PROCEDURE and an explicit EXPOSE list, the trust boundary is written down in the code: only the count. stem crosses it.

Trust and data boundaries

Two boundaries matter in practice:

External input boundary. Everything from PARSE ARG, LINEIN, or a command response is an unvalidated string. Numeric checks are cheap insurance:

if \datatype(threshold, 'W') then do
  say 'threshold must be a whole number, got:' threshold
  exit 8
end

DATATYPE(x,'W') tests for a whole number before any arithmetic touches the value. Without it, a threshold of 10O (letter O) surfaces later as a syntax error on the comparison line, far from the real fault.

Variable scope boundary. Uninitialized Rexx variables evaluate to their own name in uppercase — referencing THRESHHOLD yields the string THRESHHOLD, not an error. Use SIGNAL ON NOVALUE during development to trap exactly this; it converts silent typo-bugs into immediate halts naming the offending variable.

Operational checks

Run the script with a standard interpreter (Regina Rexx or ooRexx on Linux/macOS; the native interpreter on z/OS or z/VM). No special privileges are needed for the parsing logic itself; only the commands your script issues carry permission requirements.

rexx logscan.rexx sample.log 50

Checks worth building into the script rather than doing by hand:

1. Trace a dry run: invoke with rexx -t or add TRACE ?R temporarily to watch intermediate results line by line. Remove it before production — trace output on a large loop is enormous.
2. Verify tokenization: feed PARSE a deliberately malformed line (missing fields, extra whitespace) and confirm the template leaves the expected variables empty rather than shifted.
3. Verify numeric handling: pass a non-numeric threshold and confirm the DATATYPE guard fires with exit code 8, not a syntax error dump.

Failure modes

• Silent NOVALUE bugs. A misspelled variable is a legal string. Mitigate with SIGNAL ON NOVALUE in test builds.
• Hidden coupling via globals. If you drop PROCEDURE for convenience, subroutines can mutate caller state invisibly. In a framework of chained scripts this produces bugs that only appear under specific call orders.
• Performance collapse on large strings. Rexx copies strings freely; building a megabyte-sized buffer by repeated concatenation (buf = buf || line) in a loop is quadratic in cost. For large streams, process line-by-line or write intermediate results to a stem and join once.
• Interpreter overhead in hot loops. Rexx is interpreted; a loop issuing an external command per iteration is dominated by spawn cost. Batch external calls where possible.

Conditions that would change the design

Move to explicit parameter passing and return values (dropping EXPOSE entirely) the moment a second script starts calling your subroutines. Move numeric validation earlier — at the PARSE ARG line — if the script gains the ability to change system state. And if a single run must process more than a few hundred thousand lines, prototype the hot path first; the interpreter's string handling may force you to pre-filter with an external tool (grep, awk) and let Rexx handle only the decision logic. That split keeps Rexx where it is strongest: orchestration and text-driven decisions, not bulk data crunching.