Rexx for Everyone

An anonymous reader writes "It's easy to get lost in the world of 'little languages' -- quite a few have been written to scratch some itch of a company, individual, or project. Rexx is one of these languages, with a long history of use on IBM operating systems, and good current implementations for Linux and other Free Software operating systems. Rexx occupies a useful ecological niche between the relative crudeness of shell scripting and the cumbersome formality of full systems languages. Many Linux programmers and systems administrators would benefit from adding a Rexx implementation to their collection of go-to tools."

Comments

Yet Another...

[dacarr]

REXX was great for OS/2, but in Linux, between bash, perl, and tcl/tk, why would you need anything else?

The only answer:

[torpor]

Language Diversity.

There's no other reason. Your list could've stopped at perl, and it would still be a reason.

Its good to have diversity in your language choices, because different languages have different strengths and weaknesses, and having a good command of more than one can often make you much better, individually.

There's no reason not to continue adding scripting languages to operating systems ... strong language evolution is best served by having a massive genepool.

Or at least, so the theory goes. Of course there's the "pro at all, master of none" aspect to consider as well, but you never know ... REXX may one day compete with CPAN, you never know ... ;)

Re:The only answer:

[msuzio]

No, there's other answers. Sometimes you are trading power for bulk. Perl is very powerful, but also very "bulky". Large footprint, for one thing. libperl is about 800K on my nearest Linux box. If I can bring another language in that is more compact, that might be a good thing.

The other issue is "bulk" in terms of the scope of the language. Sometimes limits are *OK*. If I just want to script out some very simple operations, do I need Perl? Do I need my users to learn Perl?

You need to consider the topic as a whole. This isn't a defense of REXX's suitability in these roles, but a counter to the assumption that there is an "only answer".

Re:It's CobolScript for Unix!!!

[Just Some Guy]

ADDRESS SYSTEM ls WITH OUTPUT FIFO '' ERROR NORMAL

That's definitely verbose and ugly, but behind the scenes, that code just "connected" to the "SYSTEM" port, issued the "ls" command, and sent some configuration information.

PARSE PULL line

When you "ADDRESS"ed the SYSTEM object, you basically imported it's API into the REXX namespace. See that "PARSE PULL" bit? That command comes from the SYSTEM object, and isn't part of the REXX language proper. Imagine this code sample (completely invented and unlikely to work without modification, but still illustrative) instead:

#!/usr/bin/rexx
ADDRESS POSTGRESQL
SELECT * from tablename
DO WHILE rowsleft() \= 0
RETRIEVE row
ADDRESS EMAILER
SEND row TO emailuser@company.com SUBJECT "SQL Query Row"
END

Suddenly it doesn't seem quite so horrible, does it, when you realize that you can connect directly to any REXX-enabled application and control it as though you were written a script directly within that application?

I'm not saying that I'd ever for a moment consider touching REXX code again without a large monetary incentive, but you should understand that noone said "hey, this language has no redeeming values, let's use it!". It has its own unique properties, and while the ugliness outweighs the good stuff, it certainly had its niche back in the day.

Re:Yay for REXX!

[BrynM]

Write all your code in big REXX like you were a CONSULTANT at a BANK in 1988!!!... a deadly scripting language in the horrible tradition of DOS batch programs and JCL.

If you're still doing work on an S390 or other IBM mainframe, REXX is so much better to cope with than JCL. Yeah, you still have to write a small JCL wrapper for your REXX app, but that's it. None of that hard to read JCL crap that goes on forever. Unfortunately, nobody seems to remember that PERL and other C based languages have been ported over to these MVS systems... REXX to me is another example of people clinging to what they know - wich is rampant in the mainframe world (COBOL, JCL, JES2, JES3, TSO... yadda yadda).

IBM has done a great job of evolving these systems with the times, but very few shops implememnet ports of common languages such as PERL. Just try telling your Senior Systems Programmer that you'd rather use C++ or PERL or write code for your CICS regions and they would think that you were crazy because they don't want to support that code. Ironically, when the shop I worked at starting interfacing MVS and NT systems for data warehousing, my knowledge of Regina REXX on the NT boxen made the production programmers on the mainframe side more comfortable. Regina REXX even had some built in functions for the Windows Registry! REXX can be a good intermediate language for mainframe programmers to be more at home on the target platform you are moving them to. Ah, memories... Long live IEFBR14!

Re:Seems like Rexx is dying out

[trouser]

Python and Ruby are not scripting languages. They are portable byte compiled object-oriented programming languages. Hell, even Perl is a programming language.

Scripting languages offer a programming interface to automate the use of a specific tool. eg. Javascript in a browser, Bash in a terminal.

Python, Ruby, Perl and perhaps Rexx (can't be sure, haven't used it) can be used for general programming which might otherwise be tackled in C, C++, Java, etc.