× 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

Thanks for the explanations and clarifications. I agree with your points where you "disagree" with me - the speed issue is mostly insignificant, and using STRREXPRC in a loop is just plain bad technique, as you point out, and I meant to say the same thing, I think. My tongue was not evidently enough in my cheek.

I really like REXX but find that in many shops there will be resistance due to "who will maintain it when you are gone?" Nonetheless, it does its job superbly. To add to your comments, parsing the parameters of a command is a dream in REXX, compared to CL - especially lists, IIRC.

One neat thing is that array-like structure elements can be referenced by a name (text) instead of numbers, or as an alternative. This is similar, it seems to me, to what I think are called associative arrays in Perl. (Do I have the terms right, or mixed up some?) In fact, I see similarities between REXX and Perl, although I've not done much with the latter.

So preach on, brother, REXX is cool!!

BTW, there's even something called ObjectREXX in Windows - easy object-oriented programming. Didn't that language play a part in some release of WDSC or WebSphere Development Tools? Mayhaps it still does - there is usually something called RXAPI.EXE that I see running in Task Manager, and that looks suspiciously like a REXX (RX) something or other.

Vern

At 05:09 PM 8/19/2005, you wrote:

William,

Well, in my experience, REXX has more capabilities that CL, (although
things are getting closer in V5R3)  and is more like a programming
language than is CL even though CL is compiled and REXX is
interpretative.   CL is more oriented to executing programs, like a
typical command language scripting language, whereas REXX is often used
to create entire programs or functions. You can build your own functions
or use one or more of the 30 or so native to REXX.  In the late 1980 IBM
built its entire internal use only timecard system using REXX and SQL
against DB2 under VM.  I'll admit not  many people build their own REXX
programs or functions on the AS/400 like the rest of the IBM platforms
because they usually have only been taught CL and REXX has not been on
the AS/400 as long as the other IBM platforms.

That brings up the cross-platform usability of the REXX language.   It
is found on all IBM OS's that I'm aware of whereas CL is exclusive only
on the AS/400.

Even though I usually agree with Vern about a lot of things, there are
a couple of places where I disagree with what he just said about REXX
and its usage.

1.  He said it is slower.    Well, while that might be technically
correct, from my experience a REXX program will perform as fast as CL,
at least from what you and your programs can detect; usually faster than
anything you'll need.

2. He said "Calling REXX from a CL repeatedly can have performance
issues - IOW, using the STRREXPRC command in a long loop will be almost
always slower than some other means."

Herein I disagree with the approach.   I would not call REXX from a CL
program unless absolutely necessary... I'd REPLACE the CL with a REXX
program.

While a REXX program can be called using STRREXPRC, there are several
ways to call a REXX program depending on if you're calling it
interactively or from a program.   And, depending on how you code the
program, it can be called both interactively and from another program.


Often I'll create REXX programs that I want to call from the command
line.  I simply create a CMD file with one line.   When I invoke the CMD
file, it invokes the REXX program.  Or, I can call a REXX program from
almost any other language using the REXX API (QREXX on the iSeries).   I
also use it for utilities like FTP (with log files) run as a scheduled
job.

Even though I might disagree with some of what Vern said, I agree with
the following statements:

"Nonetheless, REXX is fantastic for things like string handling. It
includes functions to reverse a character string, center it in a certain
length, etc.

It has all the structured stuff that CL has never had, until V5R3 to
some extent. Writing in it is fairly easy - no declaration of data types
- it understands context with little or no problem.

It actually makes a very nice command-processing program - commands can
be pointed at a REXX procedure directly instead of a *PGM."


Let's look at a typical comparison of CL and REXX to do string
manipulation.   This should give you an idea of a few things..., easy of
writing, simplicity, power and more:

The following CL statements find the first sentence, which is delimited
by a period, in a 50-character variable &INPUT and place any remaining
text in the variable &REMAINDER:

(These examples taken from the REXX400 Programmers Guide by IBM)

DCL &INPUT *CHAR  LEN(50)
DCL &REMAINDER *CHAR LEN(50)
DCL &X *DEC LEN(2,0) VALUE(01)
etc.

SCAN:  IF ((%SUBVSTRING(&INPUT &X 1)  *NE '.')  *AND  +
    (&X *LT 50))   THEN(DO)
    CHGVAR  &X (&X+1)
    GOTO SCAN
ENDO
CHGVAR CAE(&L) VALUE(50-&X)
CHGVAR VAR(&X) VALUE(&X+1)
CHGVAR VAR(&REMAINDER)  VALUE(%SUBSTRING(&INPUT &X &L))

    Wow,  what a lot of typing.   This is the REXX statement to do the
same thing:

parse var input  .  '.'   remainder

If you want to search for a literal pattern that consists of several
characters (for example, 'QPGMR'), the CL program will become more
complex, because it treats the whole string as an array of single
characters.   However, the only changes for the REXX statement are:

parse var input . 'QPGMR' remainder


Notice, that Vern said it has all the structured stuff that CL has
never had.   Again, more like a real programming language, like C.

He also said, "Also, REXX is always interpreted. No compiled objects."
 I think you'll find REXX VERY FAST so you won't notice its
interpretive.   Also, making changes and trying them is FAST.  Invoke
the program from PDM with option 16.

If you want to turn on tracing for debugging, simply put the following
statement anywhere you wish in your REXX program depending on where you
want to start the trace: "trace 'r' (or one of the four trace variables
so you can see what variable results are, or what they are doing during
the run of your program).   When you're ready to turn tracing off, just
change the 'r' to 'o'.   I'd leave the statement in the program so you
can turn on and off when you need it.

Another real advantage is, since REXX is found on all IBM platforms
much has been written about REXX (I just did a Google search on REXX and
got 676,000 hits) and there are many, many REXX programs and functions
already written.   Therefore, if you see something you like but it was
written for VM or MVS (even against the regular UDB DB2s), it can easily
be modified to work on the AS/400 and/or DB2/400.

Lastly, REXX is free form.  You can write a program pretty much any way
you want; all on one line if you wish, though I don't know why you'd
want to.    But there are some established "norms" for REXX program
structure so someone can easily follow what its doing at the human
level.

I recommend you check out the REXX400 Reference manual and the REXX
Programmers Guide.

Take care,

Dave Odom
Arizona

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


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.