Slashdot Mirror
O'Reilly on the Virtues of Rexx
gaijincory writes "O'Reilly's ONLamp has written an interesting article on the history and virtues of Rexx, the first widely used scripting language concocted 25 years ago. According to the review, 'Rexx employs decimal rather than binary arithmetic' and 'You don't need to declare or predefine your variables. Rexx automatically allocates them when you first refer to them.'
I'd be interested to hear about any success (or failure) implementation stories."
We tried working with Rexx
An employee suggested to me that we load Rexx on a few machines here as an evaluation. I was skeptical at first but he explained the benefits of using it for our employee's day-to-day scripting. So I decided to let him install the interpreter onto 5 machines to see how the users got on. Besides, our IT manager had been using it on his system and it seemed to work fine, why not try it on the client machines?
Once he'd got the machines up and running with Rexx we let the users try it out. It all seemed fine to start with: Rexx was a pretty good replacement for batch files and the users could still do their work as normal.
Alas it did not stay that way. After a few days, I had lost count of the number of complaints received from users who could find things they were used to or tasks they could not perform that they previously could with batch files. The final straw came when one employee lost several hours work when Rexx suddenly had an error reading from our intranet file server and corrupted his project.
Needless to say, the Rexx team offered no support whatsoever. I made the employee uninstall Rexx from the machines and lets just say he's not with us anymore, because we had him killed.
Rexx employs decimal rather than binary arithmetic. [...] You don't need to declare or predefine your variables. Rexx automatically allocates them when you first refer to them. Are these supposed to be positive points? Because it kind of flies in the face of coding best practices...
Okay, I'm probably dating myself here (illegal in Nebraska, btw), but I remember REXX when it emerged as a replacement for EXEC which I had coded extensively in (written entire app systems) on IBM mainframes. There were a lot of benefits to REXX back then, notably it cleaned up and made transparent a lot of garbage and system management chores required to write clean EXEC code (e.g., strings tokenized at 8 chars, awkward variable interpolation)... I used REXX for a while on the mainframe and can't remember why I abandoned it.
Fast forward 2 or 3 hundred years, and I found myself dropped into a Unix universe, and quickly self taught myself the ins and outs of shell. Haven't looked back since. Now, I'm looking back and am intrigued... REXX really does have some interesting features. And, since I have a little free time on my hands, maybe I'll re-visit REXX, but from userland out there, any feedback would be useful:
IBM made it available for nearly all of its operating systems. In particular, it was extremely handy if you were on a VM/CMS system.
(S(SKK)(SKK))(S(SKK)(SKK))
>You don't need to declare or predefine your variables.
Isn't this a bad thing? You would never catch typos when using variables. I start using a variable named "myBigNumber" then the next day I mistakenly start using a "myBigNum" variable even though I mean the same thing.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
I thought Rexx was the name of the animated doggie on the MS search dialog.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
I used to be the VM/ESA systems programmer (king geek) for a state university (I'm still at that university, it's been over 21 years).
REXX was the first serious scripting language that IBM delivered for VM (EXEC was awful and EXEC2 not much better). Our systems development (applications) staff wrote quite a number of in-house REXX applications interfaced to DMS/CMS (this was before ISPF was very usable under VM). Most of these were working with CUFS (later Advantage). I used REXX extensively to match-merge two files, generate reports, and reformat data. I also rewrote some programs in REXX that had originally been implemented in SNOBAT (a snobol4 dialect for System/370).
Roll forward a few years. All the sudden, I'm responsible for Unix servers as well as VM. Although I installed regina on our Unix servers, I figured out pretty quickly that perl was the preferred script language for Unix (I first installed 4.0.36). I saw that there were a lot of facilities and working scripts in perl that I'd have to build for myself in REXX, so I made a point to learn perl. I still used REXX for things that interacted with our VM/ESA and z/OS & TSO/ISPF environment.
Roll forward a few more years. IBM drops HESC, and VM becomes prohibitively expensive to keep. Meanwhile, our academia is moving to Unix and PC-based teaching, and a Unix-based ERP is on the horizon. We decided to eliminate VM. I spent quite a few hours writing perl scripts to parse DMS/CMS panel sources and REXX programs, to build ISPF panels and generate ISPF-friendly REXX from the DMS/CMS REXX code (fortunately most of the code was cookie-cutter so it was easy to do a find/replace). I knew these programs would be eliminated when the ERP was in place.
Now I'm so neck-deep in Oracle (database, application server, and other toys) and SCT Banner that I maybe spend 10 minutes a day on our z/OS system, and haven't written a new program there (in any language, much less REXX) in six months. I still maintain or help debug a REXX program now-and-then.
REXX was a success, but for us VM died. I still like REXX, but perl has pretty-well replaced it for me. The last time I wrote a REXX program I caught myself writing perl-isms into it that I had to fix.
Doug
What, like Perl?
I've written scripts in REXX, and found it easy to write and easy to read at a later date. There are books available on the language. I'd recommend "The REXX Language" by Cowlishaw.
Mea navis aericumbens anguillis abundat
REXX's history isn't even really mentioned.
First of all, REXX is hardly the first popular scripting language, there were lots of them before it. REXX was designed as an alternative to EXEC2 which was a replacement for EXEC and that's just on IBM's VM mainframe systems. Listing other scripting systems prior to REXX is left as an exercise for the reader.
As for history, REXX wasn't developed as an official IBM project. It was developed as an internal tools project by Mike Cowlishaw at IBM's research lab in Hursley, England (the VENTA lab) because EXEC2 basically sucked. It was distributed on IBM's internal tools system (VMTOOLS and IBMVM) and became hugely popular inside IBM.
It was made available as an unsupported tool through the IBM VM user group and became so popular that despite IBM managment wanting EXEC2 to be the "official" scripting language, nobody in their right minds used EXEC2 and REXX became almost universal. Pressure from their commercial VM/CMS and VM/XA users forced IBM to make REXX a supported product.
In the mid 1980s, a PC version became available internally on the IBMPC and PCTOOLS systems and quite a few internal tools were written in REXX but despite internal popularity, IBM didn't release the PC version of REXX until much later when a vastly expanded (some would say bloated) version was released as a fairly expensive commercial product.
As a side note, REXX was released as a scripting language for PCs with later versions of OS/2 but by that time OS/2 was insignificant in the PC industry.
One unrelated note, Cowlishaw is also famous as the keeper of the IBM Jargon Dictionary - a tongue firmly in cheek listing of IBMisms.
The most obvious drawback in REXX is that the standard I/O calls don't work on the mainframe (where you have to use EXECIO calls), so it's not very portable. Really, REXX's biggest benefit is its tight integration with TSO (the mainframe command interpreter) and ISPF (the screen interface and editor). When REXX is by itself on other platforms, these benefits disappear. I use REXX on MVS (now called z/OS), but it just pales in comparison to Perl or Python for other environments.
Keep in mind REXX predates the adoption of C-ish syntax (C, C++, Java, Perl, Python, PHP, etc), so it's not as easy to switch gears mentally as it would be among the C-ish family. As you'd expect, the syntax has its quirks, especially if you don't use it much. None of the standard library functions has names like C's, unlike Perl and PHP. Truth be told, REXX looks a whole lot like structured BASIC.
REXX is quirky. You can use stems as associative arrays, but there is no mechanism to iterate over them. (I'm not joking.) No regular expressions built into the language like Perl has. No built-in systems programming interfaces (you have to ADDRESS the operating system to run commands, like bash, etc. - more of a flow control language like bash than an environment like Perl) While there are modern extensions like OO for REXX, they're not standard in all REXX interpreters, and are as clumsy as adding OO to BASIC, Fortran, COBOL, and other pre-C languages.
WROX has a REXX book, the only new one in ages and ages. Unfortunately, it concentrates on non-mainframe platforms where there frankly isn't as much to talk about because you don't have the tight integration with the OS.
Raises hand here, if only to lament that Rexx, at least in the form of the linux regina clone, is a poor, no, poor to the point of starving to death, comparison to ARexx, written BY William Hawes for the amiga.
It was extensible by writing libraries for it, libraries that allowed it to do anything you were of a mind to.
When I was still running a big box amiga, Jim Hines and I (we were both working at a tv station, http://www.wdtv.com/> ) and needed a cron to run some of the very time consuming rendering jobs that lots of video people were running on amiga's a decade back.
So we wrote a cron in ARexx, and by carefull coding, its cpu hit was less than we could measure. Most of the wannabe cron apps for the amiga were coded to wait in busy loops till the clock matched, and of course used 20% or more of the cpu.
Eventually I bought a copy of rexx-plus, the only actual compiler for arexx there ever was, which could build standalone programs out of your arexx scripts.
You can yet, I think, download that to run on your old amiga, from Aminet.net, search for EzCron, latest version. IIRC the archive contains both the arexx script itself, and the compiled binary.
We did things in a couple of days using arexx that would have taken weeks in C. Repeatedly.
There is yet today, a headless old 2000/040 amiga there, running EzCron, and its executing additional arexx scripts to grab the prompter files for our newscasts from the news server in the news dept., and make them available for you to read at the above site. Incomplete sometimes because the news folks get lazy and don't transcribe to the prompter, whats said in a taped segment.
But when we looked at making those arexx scripts run on linux, regina upchucked all over the place because they were doing things that Rexx never had in its repertory. If that miggy ever dies for good, we'll have to rewrite them in bash, and that will take a couple of weeks to translate I expect. Bash I believe does have all the tools to do it. But its going to take a concerted effort we haven't found the time to do yet. Normal life keeps happening...
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
No, REXX is shit. It sucks, it bites, it blows syphilitic goats through coffee stir-sticks. I'd compare it to the aborted offspring of third-generation addiction research monkeys if the Crackmonkey Defense League wouldn't picket me for it.
Why, I hear you ask, am I so violently opposed to this allegedly powerful "scripting" "language"? It's because I once had to use it.
I wrote a test harness with it. You know, one of those things that scripting languages are supposed to be good for? You'd think REXX would make such a task easy, wouldn't you? You'd be wrong.
How do I hate REXX? Let me count the ways:
You know? Procedures, aka functions aka subroutines? Those handy little things that let you subdivide your complex tasks into lots of simple ones? Ain't gottem'.
What it has is a kind of GOSUB-with-arguments that it pretends are real procedures and look enough like them that they fooled me until it was too late.
See, when you find a procedure definition in a reasonable scripting language, it's a no-op, right? It's either an expression that creates the procedure then and there or it's a thing that the interpreter finds in the source code before it starts running the program. Either way, when running through the code, the interpreter just sort of does nothing immediate when it finds a procedure definition.
So all we scripting hacks need to remember to do is to define our procedures before we use them, right?
Well, in REXX, they're labels. As soon as the thread of execution reaches a fake procedure, it wanders right in, up until it hits the RETURN statement, at which point it's an error if you're lucky or a return from some unexpected function if you're not.
And kazam! Good programming habits go unpunished.
And let's not think about the sort of spaghetti code this, uh, feature can lead to. No, really, let's not.
Since the pretend procedures are just labels, there has to be some way to monkey around with the scope to get something like local variables, right? There is. And it's vile.
There's a command (whose name I've mercifully forgotten) which creates a new global scope. You call it in your pretend-procedure and ta-da, everything's local now. Hooray, unless you want to actually access a real global variable. But they thought of that--the command lets you list the variables from the previous scope that you want to access and they get stuck into the new scope.
So far, so good, right?
The problem is that these scopes nest. So if fake-procedure FOO needs to write to global variable BLAT and declares it in its scope-creation thingy, this works fine if you call FOO from the mainline.
But what if function BAR calls FOO? Well then, the BLAT that FOO writes to will belong to BAR's scope unless BAR also declares BLAT to belong to the previous scope. And if QUUX calls BAR, the same thing happens.
So if you want to modify a global variable from a function you have to make sure that every function that can conceivably be part of its call chain cooperates. And if you mess up and don't find all of those cases, there's no warning or error message.
Y'know, there are other problems with REXX but they're not as bad. At least, I could have worked around them if I'd had a decent procedure system. A lot of language brokenness is tolerable if you only ever need to solve it once. REXX doesn't give me even that capability.
To be balanced, I should say some nice things about it:
There we go. That's nice, isn't it?