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
Check out Ruby, the language. It runs circles around Rexx, is free and very cool. True objects, all the time. Garbage collection built in, as well as everything is an object. The best of Smalltalk, Lisp, BASIC, C, and more.
--- Old Time NeXThead
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
What I remember about REXX is that it was one of the few languages (along with Model 204 User Language) that made programming IBM mainframes FUN. Of course, nowadays IBM mainframes can be tweaked to run Linux and that opens up a whole slew of scripted languages to choose from.
-- SKYKING, SKYKING, DO NOT ANSWER.
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.
- if I click on column 50 after the end of a 30-character-long line, the cursor sticks there and I can start typing - I don't have to type spaces or tabs to get to column 50
That is truly a great feature for blind users. Imagine not being able to see where the cursor is then having your editor suddenly decide to move it to somewhere else when you start typing. I can't believe editors think that tossing characters into the wrong place is acceptable in 2005. I can understand serious problems like that in 1985 when I first started using computers, but the fact that most editors are broken like that 20 years later is absurd.
PS: Why am I no longer allowed to post to Slashdot without help from someone that can see? Why the filter to prevent blind users from posting? Why does the person that runs this site hate the blind?
have made Rexx open source: get yourself some of that here
At the time however, it wasn't a relatively small group of consumers, if one was referring to consumers that use computers.
People must put things in context. The Amiga started out with a very large percentage of marketshare. It was only in its end years that market share dwindled so, via incredible growth in _other_ market shares.
For a while, REXX was a very dominant programming language. Then again, so was TCL for a while, and so was BASIC.
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.
> My disgust with Perl is leading me to use Python for scripting.
You mean the same language that has no "use strict" at all? That one?
If you can't maintain reasonably written perl code, stay the hell away from my C. You're a code grinder, not a programmer.
I am no longer wasting my time with slashdot
They say the mind is the first thing to
If you do declare variables then the compiler can perform validation that it otherwise can't and catch errors at compile time. It's a *good* thing.
Object Oriented Programming theory would disagree with you. While it's a "*good* thing" for the compiler writer it's a bad thing for the programmer. One of the four original tenets of OOP is that everything in an OOP system uses LATE BINDING so that the system can be flexible. It's only because Stroustrop couldn't get that working when he was writing his semi-OOP preprocessor to C (C++, perhaps you've heard of it) that this key part of OOP started getting ignored.
The world doesn't begin and end with what can be done easily in a C derivative language. Take a look at Smalltalk-72 to see what OOP was supposed to be.
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)
... REXX is yet another interpretive scripting language, one that is exceedingly clear and non-cryptic -- one can return to a REXX script you wrote a decade ago and understand it (try that with perl!).
And REXX has a much easier learning curve than something like perl, even easier (IMHO) than plain vanilla unix hell scripting. If you're in a large group or a group with a high turnover, you could do a lot worse than selecting REXX as a scripting standard.
For specifics as to why you might choose REXX over another scripting language in your toolkit, it has tremendous parsing capabilities (you can specify a template when you read text from the input stream, and have REXX bust up the incoming text to fit the template, adjusting case if desired) as well as very nice ways of dealing with arrays ("stems" in REXX parlance).
One of the niceties of using REXX in the mainframe world was that you could specify the environment a command string would be interpreted in. Not quite AppleScript, where you can direct scriptable apps to do your bidding, but the next best thing.
This allows you to co-opt other portions of your system to do the work for you, and not reinvent the wheel at every turn. Think of this as the "script as conductor" philosophy of scripting.
But REXX is also capable of functioning as a standalone programming environment. In the mainframe realm, I've done socket programming, dynamic sql, screen painting and more file conversions than I want to think about using REXX. I do code using a fair assortment of compiled languages, but when it's crunch time, nothing beats a good interpretive scripting facility to deliver the goods in a timely manner.
Sadly, aside from the unix/dos command shell, I don't believe many other environments are generally supported under non-mainframe REXX (I don't believe I've ever seen REXX operating as an EMACS macro, for example), but given the flexibility of the unix shell environment, that is generally sufficient.
It's still used in IBM mainframes, and is the scripting language of choice in OS/2 (which is _still_ in heavy use, though not at home).
:
For those of you NOT clued in, Rexx also comes as ObjectRexx, which, as you might guess is fully object oriented.
IBM has completely open-sourced it, and there is also a second open-source implementation (Regina Rexx).
Check out what's been going on at
http://www.rexxla.org/>
For 90% of what people use a scripting language for, Rexx beats the pants of Perl. it's easy to use and it's _readable_.
On many platforms, you can construct full GUI apps with it too, from paint programs, to GUI unzippers, etc.
Oh, it's nice enough! My preferred scripting language along with Python. I've easily written stuff like converters from BSDL (boundary scan description language) to XML, even a simulation of 3-d nuclear spin diffusion in sparsely abundant cubic lattice.
I almost forgot. The main reason it was handier than sliced bread on the amiga is that NO other language on any other platform had the concept of an ARexx "port" for direct communication from one process to another.
I don't think it was anything but a name to address translator where the buffer named had to be read before another write to it was performed else the system went up in copious clouds of profanity. But if you paid attention to your housekeeping it was at least as stable as writing to a disk file, and a heck of a lot faster.
--
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)
Aparrently REXX will call an OS command if it doen't recognise a keyword. So just plain including grep and uniq and so forth as if they were functions is allowed. How quaint! Just think of the hacks, if you misspell pront or writte or opne or some random thing, you could be running any random black-hat code and perhaps never even knowing.
Sorry, nostalgic folks. The state of the art has moved on, and not accidentally.
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?
I've worked in the computer programming trade since 1965 when I learned COBOL '65 in the Air Force. This year, in semi-retirement, in an equally demanding role, I taught three classes of Java Programming in a local high school. I enjoy Java but I must admit a love for REXX.
I presented a paper on REXX at a REXX conference at Stanford University, May 1990. The topic of the paper was on the ease of portability between platforms. Subsequently to that, I working as a programmer at Bank of America's campus in Concord, CA, I trained all programmers there who wanted to stay late in how to program in REXX on MVS, VM, OS/2, DOS, and Windows platforms, the main differences being how I/O was handled.
The course I taught at BofA was about three hours long, an hour and 1/2 for two late afternoon sessions. So the learning curve was quite low.
In addition to teaching everything they needed to know, I also showed them how to code dynamic SQL statements in REXX code. I had already used REXX in a good bit of the code used for utilities and one-time jobs for the Cash Vault System that I was working on there.
There are few languages that one can learn completely in 3 hours. The Java classes (one AP and two general) took an entire high school year and I only scratched the surface even though I covered all 19 chapters of Cay Horstmann's "Java Essentials".
Those that turn their noses up at REXX I have found to be the same sort of people who think writing code is an IQ test and if they don't write code that no one else can maintain that they have somehow failed. I don't think programming has to be difficult and the best languages are those that are easy to learn and easy to program in while being able to get the job done and run efficiently. For quick and dirty code or seldom run utilities in production, REXX is an ideal language to use. Of course, for a program that is processing 10+ million records sequentially or updating a DB2 database for millions of transactions for real time access you want to use a compilable language.