I was a VM systems programmer (System/370) in my first job. REXX was displacing EXEC2 as the EXEC language. I remember not bothering with it because I didn't have to.

The users were a mix of researchers doing statistical data analysis, and the major packages installed on the systems were SAS, ADABAS, FORTRAN, and Pascal. As a systems guy, I did quite a bit of macro assembler, as well.

One day, while waiting for a number of SAS reports to complete, I picked-up the REXX User's Guide and started reading it. The three things that struck me about REXX were the PARSE PULL command, stem variables, and QUEUEs. Parsing lets you treat strings as lists by specifying templates, stem variables are a primitive form of associative arrays, and QUEUEs are about the same as FIFOs under Unix. On top of these the scripts "compiled" effectively instantaneously, and CMS automatically cached the tokenized scripts so that subsequent calls were even faster.

I did almost all of my scripted automation in REXX from that day on.

In a later job, I worked with OS/2 IVR systems. On OS/2, REXX was billed as the next generation of batch files. DB2/2 and Oracle both shipped with REXX call-level interfaces, and the TCP/IP utilities had REXX libraries for access to FTP and even TCP/IP socket programming. There were also REXX interfaces for interacting with WPS, but I never got into those.

REXX was great for its time, but, in my opinion, it doesn't hold a candle to Perl.

Perl's major advantages over REXX are the regular expressions, the richer syntax (or excessive syntactic sugar, depending on how you look at it), and CPAN.

I remember that REXX code was a bear to maintain but I cannot remember why.

Also, I remember that after working with Perl 4 for a very short time, I quickly forgot about REXX.