When I was working on VM back in the 1980s, we became aware of, and then wholeheartedly adopted this new scripting language called REXX. We started writing REXX EXECs, as everyone seemed to call them then, to do the sort of simple stuff that we had used EXEC and EXEC2 to do before. REXX was easy to read, and fairly easy to learn and write. Everyone was creating REXX EXECs. And soon MVS people wanted to use REXX as well. And at one stage, it was being ported to lots of non-IBM platforms. It was a scripting mega-star. The Python of its day. I wanted to look at its history and see where it was today.
The hero of the story is Mile Cowlishaw who created Rexx in his own time as a replacement for EXEC and EXEC2. That was between 1979 and 1982. Rexx was designed as a scripting language that was easy, fast, reliable, and error-free. It was originally called Rex (Reformed Executor), but there were other products around called Rex, so it became Rexx (REstructured eXtended eXecutor). And, it was written in uppercase, as REXX, because most things (especially code) were written in caps in those days. Cowlishaw also planned for Rexx to be a simplified and easier to learn version of the PL/I, although he did introduce some differences. It became an IBM product in 1982. I think I first started using it in 1984 – rewriting old EXECs and creating new utilities for VM.
As I said, it was very popular, and IBM released versions of it for MVS TSO/E, AS/400, VSE/ESA, AIX, PC DOS, and OS/2. There were also versions of Rexx available for Novell NetWare, Windows, Java, and Linux. The PC DOS version appeared in 1984/5. The first compiler version came out in 1987, written for CMS by Lundin and Woodruff. There were even versions for the Atari, AmigaOS, Unix (many variants), Solaris, DEC, Windows, Windows CE, Pocket PC, DOS, Palm OS, QNX, OS/2, Linux, BeOS, EPOC32/Symbian, AtheOS, OpenVMS, Apple Macintosh, and Mac OS X.
There was NetRexx, which compiles to Java byte-code through Java source code; this has no reserved keywords at all, and uses the Java object model, and is therefore not generally upwards-compatible with ‘classic’ Rexx, but is interesting all the same, and it was designed by Mike Cowlishaw. In its early days, it was associated with the unloved OS/2 operating system
In 2005, IBM released their Open Object Rexx (ooRexx), which contains a Windows Script Host (WSH) scripting engine. This allows users to program their Windows operating system and applications with Rexx in the same way as using Visual Basic and Jscript. Both NetRexx and ooRexx are open source now.
In 1990, the first independent Rexx symposium was held, which led to the forming of the REXX Language Association. In 1996, the American National Standards Institute (ANSI) published a standard for Rexx: ANSI X3.274–1996 “Information Technology – Programming Language REXX”. The Standard was renewed in 2006.
Here’s a simple dataset member:
/* REXX */clearsay “hello world”exit
It can then be run from TSO using the command:
tso exec ‘filename (membername)’
More recently, users can run Rexx from Zowe using the CLI from a Windows, Linux, or Mac console:
zowe tso issue command “exec ‘filename(membername)'” — ssm
A commercial Rexx compiler can produce native object code, which is a good way of optimizing performance.
The popularity of Rexx probably peaked in the 1990s. But there is still lots of code written in Rexx that gets used every day. Even so, in 2020 there are still a lot of z/OS (MVS) batch jobs that are using Rexx procs, although, perhaps, fewer and fewer people maintain these procs. Having said that, there are groups on LinkedIn for ‘rexx programming’ and ‘Programming in REXX’. There was a huge amount of stuff written in REXX. People used it for system user exits, or instead of CLISTs for ISPF dialogs. It was a quick way to write some code to test something out. And those people still using it are very enthusiastic about it.
It’s great to see that Rexx is still alive and well. It’s probably still worth learning because so many mainframe tasks can be done so quickly and easily using. It may also be worth looking at some of those older REXX routines that run in batch to see whether their performance could be improved. It’s a shame to see that Rexx is in many ways being neglected at many sites. After all, it is an amazingly powerful language and it is very easy to learn and use. And, longevity isn’t a bad thing in mainframe computing. So, it’s still remembered at many sites, but perhaps not as well as it should be.
