Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Technology IT

O'Reilly on the Virtues of Rexx 330

Posted by CowboyNeal from the langauges-that-time-forgot dept.
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."
This discussion has been archived. No new comments can be posted.

O'Reilly on the Virtues of Rexx More

O'Reilly on the Virtues of Rexx

Comments Filter:

  • You asked for it (Score:4, Funny)

    by Anonymous Coward on Saturday May 28, 2005 @10:48AM (#12663903)
    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.
    • 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.

      Aaah... so *that's* what happens when programmers on those Russian-based DDOS attack blackmail schemes mess up. (^_^)

      Seriously, funny twist on an otherwise cut-and-pasted troll article... you still deserve to stay at -1 though :-P
    • This is a funny folks. If I had any mod points I'd do it.

    • Re:You asked for it (Score:3, Informative)

      by ebuck ( 585470 )
      A very clever play on words that seems to be something like the old "fill in the blank" stories.

      Was around a few posts back, but then it was about deploying JAVA on the desktop.

  • Success/failure stories? (Score:5, Informative)

    by Stavr0 ( 35032 ) on Saturday May 28, 2005 @10:50AM (#12663913) Homepage Journal
    Let's see, it was the Amiga and OS/2's official scripting languages. Nuff said.

    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...

    • VM/CMS (Score:4, Informative)

      by bsd4me ( 759597 ) on Saturday May 28, 2005 @11:02AM (#12663959)

      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.

      • Quite. I first learned of it while working on a project with IBM in the fall of 1984 (linking mainframes to multibus systems). At the time, it was way better than anything else I'd run into before, but being only available in mainframes at the time, that week was the only exposure I ever really got to it (I was doing firmware in the interface card, and went to IBM for a week to help build a demo). FWIW, I really enjoyed working with the IBM engineer from Sweden, but since they hadn't connected to the net

    • Re:Success/failure stories? (Score:2, Funny)

      by Anonymous Coward
      Latin was a good language, too. Unfortunately, the environments that supported it are no longer widely available or used.

      (There is no Rexx in most ATMs...)

    • Re:Success/failure stories? (Score:4, Interesting)

      by jwdb ( 526327 ) on Saturday May 28, 2005 @12:15PM (#12664274)
      Are these supposed to be positive points? Because it kind of flies in the face of coding best practices...

      I take it you've never heard of LISP? It's a dynamically typed language that, despite being a few decades old (4 or 5 I think) is still seeing some decent usage. I believe the backend of Yahoo Stores is written in LISP, for example.

      Defining your vars beforehand is good practice for strict, structural coding projects and languages. If you're working in a flexible language and you know what you're doing, it's rather unnecessary (not that I can claim to, but I'm learnin').

      Jw
      • I believe some of the prejudice against dynamical typing is related to poor scoping (look for the Javascript example someone posted) and the possibility of accidentally introducing a new variable if you happen to misspell one. Neither of these is a problem in Lisp, though. I don't know about Rexx.

        • Definitely - not having to declare a variable and thus causing a mispelled one to be treated as valid is a problem.

          SQR has the same problem, which has bitten me more than once. And it's REALLY hard to visually detect, although you can usually use your editor's search function - if it doesn't find the variable where you expect it to be, you know there's a problem.

    • Re:Success/failure stories? (Score:4, Insightful)

      by daviddennis ( 10926 ) <david@amazing.com> on Saturday May 28, 2005 @01:01PM (#12664451) Homepage
      I don't think Rexx had a lot to do with the failure of the Amiga or OS/2 in the marketplace. Curiously enough, both of them had their deeply loyal adherents, and perhaps REXX was one of the reasons.

      I have to admit that as a general rule I perfer languages that don't force me to declare variables, especially for simple projects. Or perhaps I just get tired of hearing stilted, bureaucratic language like "best practices".

      That being said, what's wrong with decimal arithmatic? It has the major advantage of eliminating the tiresome rounding errors that make doing financial calculations in (say) Perl so annoying.

      I thought the examples showed a very interesting way of thinking. I probably won't learn or convert to REXX but I can see that it's a very forgiving environment, and I think that makes life more pleasant overall, especially for beginneers. I can see why it's popular in cultures where C and Perl didn't start with overwhelming advantages.

      D
    • The failure of the Amiga wasn't due to Rexx. If anything Arexx helped keep the Amiga in use for years. Lightwave users missed not having Arexx on the Windows port. The failure of the Amiga was due to the execs at Commodore. They'd rather take trips to the Bahamas than do any real marketing. -Andrea-

  • some issues.... (Score:5, Interesting)

    by yagu ( 721525 ) <{yayagu} {at} {gmail.com}> on Saturday May 28, 2005 @10:51AM (#12663915) Journal

    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:

    • Are there any performance issues with REXX, especially for large implementations?
    • How much can you do self-contained in REXX today? One of the things I like about a language like perl is it really abstracts a lot of utilities otherwise passed outside of perl's purview, shielding coders from having to write platform specific snippets for portability. From the examples it looks like REXX takes the other philosophy and encourages dropping out momentarily to execute a native system command or utility.
    • Like perl, are there ways to be strict with REXX (it wasn't totally apparent from the article)?
    • Is REXX really that popular out there? The article seems to think REXX is one of the most popular languages, but other than me I can't name a single other programmer I've known who writes/has written REXX applications. Maybe this is only a European seed for now (in the article).
    • Is anyone else uncomfortable with case insensitive languages? That was one of the things I'd hoped REXX would address when it came out as a replacement for EXEC, I've always thought aside from the confusion factor of ignoring case (ever lose a file in Windows because of this?), not distinguishing case throws away an entire semantic of elegance for creating better and more maintainable code.

    • Re:some issues.... (Score:3, Interesting)

      by Foz ( 17040 )
      I can't name a single other programmer I've known who writes/has written REXX applications.


      *raises hand* I used to use REXX extensively when I worked at Toyota. I used it on the OS/2 machines as well as the mainframe. I even used Visual REXX occasionally.

      I loved REXX. Gave it up when I moved to perl though. It is a very nice scripting language with a rich feature set.

      -- Gary F.
      • Same here. I used to use REXX (and later VxREXX) all the time when I was doing OS/2 systems engineering.

      • Re:some issues.... (Score:3, Interesting)

        by RetroGeek ( 206522 )
        I also used REXX a lot, along with Visual REXX.

        REXX has a wonderful String parsing capability.

        And as for OS/2, as Rexx was the official scripting language, many applications came with REXX aware libraries. You could script directly for the application.

        For instance you could write a script for an email program to manage incoming mail. Or for a FAX program, etc.

        Yes other programs in the Windows (and Linux) world have macro languages, but each syntax is different. With OS/2 and REXX you only needed to lear
    • Yes, we still use REXX for scripting on mainframes.
    • REXX is still used as a scripting language in the administration of some DB2 databases.

    • Re:some issues.... (Score:5, Insightful)

      by TheAncientHacker ( 222131 ) <TheAncientHackerNO@SPAMhotmail.com> on Saturday May 28, 2005 @11:54AM (#12664182)
      Is anyone else uncomfortable with case insensitive languages? That was one of the things I'd hoped REXX would address when it came out as a replacement for EXEC, I've always thought aside from the confusion factor of ignoring case (ever lose a file in Windows because of this?), not distinguishing case throws away an entire semantic of elegance for creating better and more maintainable code.

      No, actually you misplacing files because the case wasn't what you expected on an old Windows 3.x system was the result of using badly ported case-sensitive tools in a case-insensitive environment. (btw: Windows has always been case-insensitive and case-preserving in the NT codebase)

      Case sensitivity is, frankly, not only useless but flat out stupid and a vast step backward as it doesn't match human readable languages or other human experience thus breaking the paradigm of programming language as translator between human intent and hardware inflexibility. It leads to huge numbers of easily avoidable errors, increased maintenance time and cost and increased overall development time while providing no benefit. Sure, it makes life a little easier for lazy compiler writers and it's habit in people who've never bothered to learn any languages not derived from C but the point of a programming language is to make things easier for the human and not the compiler. Read some code in PL/I or ALGOL or LISP or Smalltalk or SNOBOL or, for that matter, REXX and you may expand your idea of what a language can be.

      Other signs of C-blinders are thinking that three-part loop constructs are a good thing, that curly braces are actually either ergonomic or intuitive or that semicolons are how you end sentences;
    • Hey old timer! Do you remember FList? I loved that thing. When I moved over to OS/2, some company in the UK was making a version for OS/2 (text mode), but it was soon abandoned before it got released. Saddest day of my life. *sigh*

      I'd still prefer a good implementation of FList to any other directory utility I've ever seen. And since I was on an Amiga for awhile, I've seen quite a lot. :)

    • Re:some issues.... (Score:3, Interesting)

      by vegaspctech ( 769513 )

      I can't name a single other programmer I've known who writes/has written REXX applications.

      REXX was my Swiss Army knife for the last two BBSes I ran. I used it to fetch FidoNet mail for our network, test and process files from FidoNet file echos, pull and convert newsgroup content, mirror ftp sites, let users of my public BBS chat with users of my private BBS, handle fax transmissions coming in on the BBS lines and to do most anything Maximus or RemoteAccess didn't do out-of-the-box or didn't do the way

  • Rexx automatically allocates them when you first refer to them.

    Well, thanks for the heads up. I imagine that they are variant types too.

  • Is this good? (Score:5, Insightful)

    by GoofyBoy ( 44399 ) on Saturday May 28, 2005 @11:02AM (#12663965) Journal
    >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.

    • Re:Is this good? (Score:3, Informative)

      by Nataku564 ( 668188 )
      In some languages, like perl, the compiler will warn you about dynamically allocating variables if you have the appropriate options turned on. I am not sure if REXX has a similar flag. The dynamic scope of variables was mostly a feature for people who were just writing shell scripts and what not, where you only had global scope anyway.

    • Re:Is this good? (Score:3, Informative)

      by Pig Hogger ( 10379 )
      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.
      It is, indeed, a bad thing.
      This is why I *ALWAYS* begin my PHP scripts with:
      error_reporting( E_ALL );
    • Its a *scripting* language. If you're taking days to compose a script, perhaps its not appropriate for the task. The idea is to be able to quickly gin something up to complete a task. Having to declare variables and work out types for everything makes the use of a script less of an efficiency gain.

      • Re:Is this good? (Score:4, Interesting)

        by multipartmixed ( 163409 ) on Saturday May 28, 2005 @11:45AM (#12664145) Homepage
        There is no requirement to work out types in order to declare variables.

        Dynamically declared are a terrible, terrible, terrible thing.

        Take the following JavaScript excerpt:


        function foo()
        {
        for (i=0; i < 10; i++)
        hello();
        }

        function bar(world)
        {
        for (i=0; i < 10; i++)
        foo();
        }

        bar(i);

        How many times does hello() run? It looks like it should run 100 times. But it only runs 10 times.

        Add "var i" to each of those functions, and it behaves as expected.

        Javascript in many respects is a good (core) language. With better inheritance and a few other tweaks, it could be an excellent scripting language. But dynamically allocated variables really, really hurts it.

        • Re:Is this good? (Score:5, Informative)

          by qbwiz ( 87077 ) * <john@baumanfamily.c3.1415926om minus pi> on Saturday May 28, 2005 @11:56AM (#12664191) Homepage
          The problem is just how javascript defines dynamically allocated variable. Try to do the same thing in Python and it will work the way you want it to.
        • Well, that's just dumpness on the part of Javascript. In most scripting languagess, it will indeen run 100 times.
        • Dynamically declared are a terrible, terrible, terrible thing.

          You're missing the point of REXX. It's a string processing language which is used to glue OS and apps. Variables are initialised as strings (uppercase version of string name). Numbers are parsed as strings until you perform an operation on them. If you DON'T want something to be a string, then explicitly type it. Otherwise, the interpreter will do it for you based on the operation you're performing.

          In its native environment (OS/2 or AREXX on
        • There's a small problem in your reasoning in this example. You're assuming that there exists a universal standard of what a programming language "should" do, and that happens here to be based on a C worldview.

          It "should" do what the language specification says it should do. Part of knowing any language is knowing its scoping rules. You say "It looks like it should run 100 times," but the first thing that went through my mind when I read that was not "Assuming C's scoping rules, it should run 100 times,"
      • I think you've touched upon why so many people think that, for instance, Perl sucks: there is no end to the people who encourage you to be sloppy; hence there is an incredible amount of sloppy, unreadable, unmaintainable Perl code. In fact, if you read Perl books by some of the most prominent Perl gurus they often push the TMTOWTDI-slogan, which makes me wonder: why are these people teaching other people how to program?

        I've worked with a lot of TMTOWTDI'idians and I can't say I enjoy it. It is very lim

        • There is no end to people who encourage you to eat bad food, drink too much and smoke. So?

          I've coded large systems in Perl. The fact that one _can_ be sloppy is no impediment. I'm also slowly improving a largish app in Java I inherited. The code blows. Complete spagetti, with silly uses of beans that do nothing but delegate to deeper classes, such brilliant encapsulation as a rollback function that, if it doesn't have a DB handle, goes and gets a new one, and of course all of the idiotic restrictions of T

    • Isn't this a bad thing? You would never catch typos when using variables.

      Definitely. I used to do a lot of ARexx programming on the Amiga, and I have spent hours trying to figure out why my script wasn't working quite right (it would run without giving any errors, but do the wrong thing), only to eventually find out that in one place I had a tiny typo in a variable reference, causing it to use the value '0' in the calculation instead of the proper value.

      Having to declare variables is annoying, but t

    • >You don't need to declare or predefine your variables.

      Isn't this a bad thing?

      For some problems it's a bad thing, for others it's a good thing. It's actually a good thing on some small projects as it adds some flexibility and the cost of accidental variable declaration doesn't rear its head until the project gets large or gets multiple people working on it.

      And your example is, by the way, also a great explanation why case sensitivity is a bad idea. For example, "I start using a variable named '
      • So, I suppose, you consider MYBIGNUM, MyBigNum, and myBigNum to be the same variable? According to many coding conventions, the first would be a constant, the second a function, and the third a variable. Case sensitivity is definitely useful.
    • It's not about "bad" versus "good". Every programming language makes tradeoffs between two conflicting goals: making it easier for the programmer to create code quickly and easily, and safeguarding against programmer error. Every restriction you could build into a language has vehement fans who consider it necessary to writing safe code, and rabid opponents who think its a stupid restriction that any truely competent programmer doesn't need. Requiring that a programmer declare variable is only one of many s
  • I had moved over to the OS-360 to do do PL1/COBOL/RPG in the 80's. REXX was there to play with. I found myself doing all sorts of fun stuff with it. Fairly easy to use. I still think of it like being a very very skinny perl.
  • I'm a sucker for bleeding edge.

    I was using OS/2 back in the day (I used Linux too). Windows was just too mainstream.

    I found that OS/2 had a new scripting language that I hadn't seen before. Wow, a new thing I can learn to stay ahead of the curve.

    I spent quite a bit of time learning it before I found out that it was old even then (1994).

    Well, it wasn't bleeding edge, but it was still fun and it beat the pants off of DOS .bat files.

    Good times.
  • Some olde ex-mainframe guys at work have some Rexx manuals and one guy wrote a small utilitiy in Rexx. (these were the same people that had extensions to vi (.exrc's) to make it work like their mainframe editors...uhm, get out of the past?)

    So thats great and all, but why are you programming in a professional capacity in a language that no one can maintain? Thats worse than hacking code in perl and not "using strict"!

  • And all these years (Score:4, Funny)

    by Timesprout ( 579035 ) on Saturday May 28, 2005 @11:17AM (#12664026)
    I thought Rexx was the name of the animated doggie on the MS search dialog.

  • Ruby Doobie Doooo (Score:2, Interesting)

    by OSXexpert ( 859428 )
    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.
  • On Windows, a truly wonderful and overlooked text editor, with REXX underneath, is KEDIT from Mansfield [kedit.com].

    Among its GUI editing features I find essential for everyday work are (1) an underlying model where the screen is a giant xy plane of characters, like a paint program, rather than a sequence of varying-length lines - 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; and (2) seamless

    • Re:The KEDIT editor (Score:2, Interesting)

      by Anonymous Coward

      - 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

    • > if I click on column 50 after the end of a 30-character-long line, the cursor sticks there and I can start typing

      It goes without saying that emacs is quite capable of this feature too. I thought it was built-in, but apparently not ... There's picture-mode, but that behaves differently than you expect (it's made for ascii line drawings). Rectangle copy and paste is also supported in emacs by holding down the alt key. It does appear to have the broken behavior of not extending the rectangle into anywh
    • Mansfield's KEDIT is a port of the old VM editor XEDIT. You might want to search for other XEDIT ports although KEDIT was the best for years. There used to be quite a few out there. In fact there were enough that PC Magazine did a comparison of XEDIT clones. (btw: I personally don't like the XEDIT family but editors are a very individual thing)
    • kedit is an amazing piece of software. Kedit provides a simple interface for things like:
      • Manipulating multiple files in the ring buffer. Such as search and replace, Tiled display, etc.
      • Folding. Selectively display lines based on simple commands like:

        ==>all "word" and
        ==>less "removeword" and
        ==>add

        I have yet to get vim do this.
      • Easy block or column editing
      • Incredably fast when editing large megabyte files.
      • Handling nl and cr all form imaginable.

      Once a year I contact the

  • My past life in REXX (Score:4, Informative)

    by dougsyo ( 84601 ) on Saturday May 28, 2005 @11:25AM (#12664057)
    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 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.
    • Heh...

      Ya, I spent six years in the COBOL mines back inthe 80's. And most of what I did was damn boring. But I could do some cool things with REXX in my spare time. What I liked best was the ease of parsing strings with it. Plus it was integreated pretty well into TSO/ISPF, so I could extend the editors and programming environment with it.

      I never wrote a production application in REXX. But I wrote plenty of utilities to make my life easier and some of them took on a life of their own. One of them I wrote a
    • that was my motivation as well: after writing cobol, jcl, cics, and ims dc & db - rexx was just really fun.

      Since it was the macro language for ispf - i first wrote about twenty macros - so you you could put the cursor on a filename, hit a pfkey and automatically browse the file, etc, etc.

      Wrote code that would convert a cobol program to cobol II (all periods except one replaced in every paragraph by scope terminators, etc). Then systematically converted *hundreds* of programs to this newer style.

      Wrot

  • History? I don't think so (Score:5, Informative)

    by TheAncientHacker ( 222131 ) <TheAncientHackerNO@SPAMhotmail.com> on Saturday May 28, 2005 @11:30AM (#12664084)
    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.
    • One unrelated note, Cowlishaw is also famous as the keeper of the IBM Jargon Dictionary - a tongue firmly in cheek listing of IBMisms.

      Is this the same one that lists the FAMD -- "Forced Air Movement Device" -- a four-letter acronym for a three-letter word?

      Rexx was pretty neat on the amiga as an IPC mechanism, namely REXX ports. As a language, I always found it pretty mediocre.
  • AREXX [wikipedia.org] is the Amiga variant that brought REXX to the consumer. Well, to a relatively small group of consumers, as it were. :-) Interesting reading, though.


    blakespot

    • 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.

  • /bin/sh is older (Score:4, Informative)

    by js7a ( 579872 ) <`gro.kivob' `ta' `semaj'> on Saturday May 28, 2005 @11:38AM (#12664121) Homepage Journal
    ... Rexx, the first widely used scripting language concocted 25 years ago.
    Rexx v1 was released internal to IBM in 1979, and wasn't available to IBM cumstomers until 1982. Steve Bourne wrote /bin/sh at Bell Labs in 1974, and it was included in every Unix distribution from 1976 to the present.
  • have made Rexx open source: get yourself some of that here [sourceforge.net]

  • REXX benefits and drawbacks (Score:3, Informative)

    by scottsk ( 781208 ) on Saturday May 28, 2005 @11:52AM (#12664175) Homepage

    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.

  • One nice thing about REXX is its "outside environment" concept. This basically anables it to be added to about anything which accepts commands. For example, EMX's gdb port for OS/2 added REXX support. This way, you could actually write "debug scripts". See an example in this usenet posting [google.com].
  • One of the reasons I like Perl, especially for prototypes, is automatic variable memory management. The interpreter automatically instantiates/allocates variables whenever you first use them, then deallocates them when they go out of scope (which is global unless otherwise directed), or when directed to "undefine" them. Memory leaks, double frees, "should I free this copy now that I'm done, or does something else use it?", duplicate pointers... none of that hell gets in the way of the algorithm, unless you

  • ARexx, too bad Rexx didn't grab its featurelist. (Score:4, Interesting)

    by Almost-Retired ( 637760 ) on Saturday May 28, 2005 @01:07PM (#12664478) Homepage
    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)
    • 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 fi

  • it all depends... (Score:3, Informative)

    by constantnormal ( 512494 ) on Saturday May 28, 2005 @01:08PM (#12664481)
    ... 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.

  • Look around! (Score:3, Informative)

    by Atomic Frog ( 28268 ) on Saturday May 28, 2005 @01:14PM (#12664505)
    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.
    • sadly, in the last 2 years OS/2 use in ATM and POS systems went from over 80% to under 30% as a version of Windows replaces it. The mainframe market from IBM continues to grow at over 20% per year, but of course that's not many machines (just a heck of alot of users)
  • I used to program on a VM/CMS machine, and we used REXX. The first line in every file had to be a comment. My usual comment was: /* IBM REXX LIVES! */

    which changed meaning depending on how you pronounced the third word...

    Baz

  • From a gentler time (Score:3, Insightful)

    by Julian Morrison ( 5575 ) on Saturday May 28, 2005 @01:47PM (#12664678)
    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.
  • The BitNET RELAY server for VM/CMS was written in REXX.

    Damn, I feel old.
  • If the slashdot submitter had just bothered to google for "rexx", then that would've answered all of his problems.

    RTFG.
  • For someone who HATES programming, and I really do, I started playing around with it when it came as the scripting language in a TELNET program I used years back called ZOC [emtec.com] before I used Linux and was stuck on Windows.

    I also was heavily into online MUD realms, and ran a Worldgroup/Galacticomm BBS with MajorMUD [turbosentry.net]- a very expensive addon MUD realm. Well I came up with the idea to create an online database that combined all the data from all the realms and put it together in a nice ranked website of all the

  • NOOOO!!! EEEEVIL!!! EEEEEVIL!!! (Score:4, Informative)

    by cgreuter ( 82182 ) on Saturday May 28, 2005 @05:07PM (#12665885)

    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:

    1. REXX doesn't have procedures.

      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.

    2. REXX's pretend procedures are just labels.

      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.

    3. Local Variables Aren't.

      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:

    1. It's much less horrible than OS/2 batch files. I'll even go so far as to say that if all you've got on hand is REXX and your program isn't going to be more than 60 lines or so, you're all set.
    2. When people complain to me about some of the irritations in Python or PHP or Perl, I just tell them about REXX and they go away.
    3. I'll never need to use it again.

    There we go. That's nice, isn't it?

Slashdot Top Deals

Work without a vision is slavery, Vision without work is a pipe dream, But vision with work is the hope of the world.

Close