× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Dave Odom wrote:

And yes, REXX is very powerful and common in IBM.  Makes me wonder why
people use CL.

Dave:

After you, you might not find a bigger fan of REXX/400 on this list than me; but I'll regularly use CL, _especially_ ILE CL, instead of REXX for the vast majority of functions when the choice is between the two. (And if it involves _any_ product code that goes to a customer, there won't be a hint of REXX in it.)

So, I'll step in to discuss from the other side.

I'm not aware of anything that can't be done in CL without requiring REXX, and I can think of a lot of things that can't be done in REXX without requiring CL. I have learned that Qshell utilities can be used in place of CL for most of those things, via [ address "QSHELL/QZSHQSHC" ], which is pretty cool, BTW. Still, a lot of the IFS is out of reach for REXX itself, a major irritation to me. Or try simply changing the owner of an object in REXX without using CL, e.g., CHGOBJOWN or CHGOWN CL commands.

For many management functions, REXX does little more than provide a framework for executing CL, one interpreted command at a time. All of the REXX tends then simply to obscure the real CL that does the work.

Another element, REXX _must_ have a source member in order to run. CL only needs the member at creation time. Once created, the source can be kept separately. If necessary, CL can even generate a source file and member at run-time and populate it with REXX statements that can then be passed to the QREXX API. Try doing something similar in REXX; if there is no source file and member at run-time, REXX won't get very far.

Rather than having a series of REXX statements that are interpreted and that themselves create strings that are then interpreted by the command environment and executed, a CL program has the strings interpreted by the compiler at compile-time. The resulting program runs at compiled speed without needing to wait for the REXX environment to be created. The fundamental parsing and syntax checking is long out of the way.

ILE CL goes far beyond OPM CL. It provides bindable procedures that REXX can't touch at all.

With REXX needing to execute CL commands so often, a REXX programmer needs to be familiar with both REXX and CL. Yet, a CL programmer gets by without REXX easily. I'd guess that the majority of CL programmers _never_ need REXX. And I'd guess that the majority of REXX/400 programmers _regularly_ need CL. (A REXX/400 programmer who never uses CL is probably doing a very large amount of unnecessary programming.)

To REXX's credit, many CL and other programmers who never use REXX are also doing extra work. REXX provides some superb shortcuts. That's why I use it. I have a few procs that I rely on over and over again and wouldn't want to code in another language. I even have a REXX/400 version of the old ELIZA 'psychotherapist' proc that I converted years ago from some early form of PC BASIC. (I never did much beyond making it work and never got so far as making it work well.) As simple as my ELIZA version is, it's clearly better suited for REXX than CL.

But IBM seems to treat REXX/400 with less respect than is shown by those who use it. IBM came up with Object REXX and recently released it to the open source community. AFAICT, there was never any serious thought to bringing it to OS/400 even though OS/400 is object-based. Nor has there been a hint of _anything_ else advancing in REXX/400 since... hmmm... since...?

Well, who wants to get held back by some old "legacy" language that can't even invoke a procedure? If IBM ignores it, why care?

Tom Liotta


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.