(Cross-posted from my personal blog.)

The other language I learned while at CDI was Rexx. First, a little background on VM/CMS.

In CMS, files have an eight character file name, an eight character file type, and a one character code specifying which minidisk the file is on. The original CMS command interpreter supported simple scripting by putting commands in a file with type EXEC. This is very similar to shell scripts in Unix. The EXEC scripting language was very basic, so after a while an extended version, EXEC 2, was added, with a few additional features and the removal of some restrictions, like token size and line length. The file type was still EXEC; you start an EXEC 2 script with a &TRACE statement (which doesn’t exist in EXEC) to distinguish between the languages. Then in 1982 IBM released a newer, much more powerful scripting language named Rexx, created by Mike Cowlishaw. The file type was still EXEC; this time you started a Rexx script with a Rexx-style comment (which I think has to include “REXX” somewhere in the first line) to let the system know it should be processed as a Rexx script. So when I started working at CDI in 1985, Rexx was the new hotness in CMS scripting. IBM later ported Rexx to most if not all of its operating systems, and it has been ported by others to many other environments.

Since it was designed for scripting, almost any line of text can be a valid Rexx statement. If the interpreter doesn’t recognize it as Rexx code, it passes it to the host environment as a command for that environment. What the host environment is depends on how or where the script was invoked, and can be changed by the Rexx ADDRESS command. When I was coding at CDI in the CMS environment, the host environment for a script could be the XEDIT editor, CMS itself, or the VM control program (CP). If a Rexx script was invoked as an XEDIT macro, for example, commands would go to the editor bylaws default, but if you needed to, say, issue a CMS command you would just prefix it with ADDRESS "CMS". The mainframe implementations have a fairly well-defined interface so you can create your own environment if that’s what you want to do. There’s also a well-defined API so that assembler programs called from a Rexx script can access and set Rexx variables, and this has been done so that many MVS facilities, like RMF or SDSF, can be automated using Rexx.

Rexx has an interesting approach to variables. Variable names are case-insensitive: Rexx always internally converts them to upper case. You create a variable by assigning a value to a name. If you reference a variable name that has never had a value assigned to it, Rexx just uses the (upper case) name. If you want to make sure something that could be a variable name is just treated as text instead of a variable, you put it in quotes. As an example, suppose you had a Rexx program that included:

bar = "ABC"
"FOO" bar baz

Then, assuming “BAZ” had never been assigned a value, “FOO ABC BAZ” would be passed as a command to the host environment. Another thing about Rexx variables is that their values are always text strings. If you use a variable in an arithmetic statement (like with ‘+’) Rexx will internally attempt to convert the value to a number, perform the operation, and then convert the result back to a text string.

Another cool thing in Rexx is “stems”, which are basically associative arrays. (This is the only kind of array Rexx supports.) A stem is a variable name followed by a period followed by a variable or value which serves as the key to identify which element of the array is being referenced.

Rexx has a fairly powerful PARSE command for extracting data from text strings. (As far as REXX is concerned, all data is a text string.) It’s not as powerful as regular expressions available in Perl, Ruby, Python, and other more recent scripting languages, but on the other hand it’s very good for extracting data from fixed positions, which is non-trivial (if even possible) for regular expression engines.

The wikipedia article I linked says that Rexx is considered a precursor to scripting languages like Tcl and Python. In most cases I would prefer to use Python, but if you’re working with one of the environments with robust Rexx integration it is a good choice.

(Cross-posted from my personal blog.)

Shortly before I finished my mission, my father quit IBM and started working for Billings Computer, a company that built microcomputers in Provo. So after my mission I lived at home, where there were several Billings computers available for us to play with. Like most microcomputers in that time, Billings computers came with a BASIC interpreter so you could write your own programs.

As an aside, Microsoft is celebrating its fiftieth anniversary this year—if wikipedia is to be believed April 4 is the actual anniversary of its founding—and two days ago Bill Gates posted a remembrance that includes a downloadable PDF of the source code for the BASIC interpreter they wrote for the Altair 8800. This was the first thing Microsoft (Micro-Soft in those days) ever did.

Anyway, I did play around with writing programs in BASIC on those computers. I remember I wrote a game to play Blackjack.

Since it’s been years since I did any BASIC programming I don’t remember much about it. I’m sure the language has changed since then. It was designed to be easier to learn than languages like FORTRAN and COBOL (not to mention assembler or machine code) and I think it succeeded in that. Like most languages of that era, though, it lacked facilities for building higher-level abstractions. I don’t feel any nostalgia for BASIC at all.