RE: prob- reverse a string in cl * REXX is very interesting.

midrange-l-request@xxxxxxxxxxxx wrote:

>   3. RE: prob- reverse a string in cl *  REXX is very interesting.
>      (Dave Odom)
>
>As to your experiment with CL and REXX... as I mentioned, to me,
>calling REXX from CL is about like using two programming languages when
>the one with the greatest function is the tool to use.   While calling
>REXX from CL can be done and is sometimes the best toolset to use, why
>use CL when you can use REXX to do the same thing and more.    

Dave:

Note that there is no way that I know of to invoke a REXX procedure (AS/400) 
without CL. This is done either through the STRREXPRC CL command or a CALL CL 
command. (The CALL might call an RPG program that then calls the QREXX API, but 
you're going to go from CL to REXX one way or another.)

Granted, a REVERSE() function executed 1000 times totally within REXX/400 will 
be much faster. No argument there. But I'm not so sure about one REXX/400 
procedure invoking an external REXX/400 proc 1000 times -- hmmm... I would 
expect some improvement, but I'm not sure how much.

But REXX/400 has definite limitations. There are a whole bunch of things that 
REXX/400 needs to do via-interlanguage communications. Simple formatted 
displays is a big example. REXX must issue CL commands at the least to 
accomplish that and they're not trivial. Nor does REXX/400 have much use for 
anything outside of the /QSYS.LIB file system. Further, many APIs that might be 
useful are unavailable since REXX/400 has no way (AFAIK, please teach me 
otherwise) to handle pointers directly nor pass parms by VALUE.

Having the outermost wrapper be REXX, or at least having a layer above any REXX 
proc that is multiply invoked be REXX, should cut some overhead; but it doesn't 
seem to. Invoking it all from REXX gives essentially the same timings. 
Apparently, accessing an external REXX/400 proc simply isn't very efficient.


>And as your experiment showed, if you want to call REXX from CL or RPG
>because REXX can do some operation simpler/easier or whatever, then use
>the API; don't call the REXX processor each time.   But, as with any
>tool, if used correctly and it the right place, it provides lots of
>function and feature and makes the work easier.

AFAIK, the API does effectively the same as the STRREXPRC command does and the 
command possibly is more efficient than how I called the API. But I wanted the 
API to get a better idea of how REXX might work within any language. I don't 
think it made a significant difference in this case.


>Usually, the biggest hurdle for AS/400 folks is getting over the
>thought of substituting REXX for CLP as it's seen as blasphemy to use
>anything except the standard CL and RPG.

I have no qualms about REXX as such. I really appreciated REXX under OS/2, 
particularly visual REXX (VisPro REXX as well as Visual REXX from IBM). I've 
used REXX/400 for some pretty involved embedded SQL work as well as to 
manipulate UIM APIs for formatted displays and printed output for example. Even 
SQL isn't truly "embedded" AFAIK. It seems to be almost a special-case of 
dynamic SQL.

But it's not so easy to fit into an application (especially 3rd-party 
products!) An unfortunate aspect of REXX/400 is that it _must_ be interpreted 
from source. That implies source that may be changed unpredictably. Nor are any 
of the really useful REXX facilities such as netrexx available (AFAIK). 
(Hmmm... AIX versions? I.e., PASE?) Until a REXX/400 compiler shows up, 
REXX/400 will remain on the fringe.

For this particular item, I was interested in something more precise than "it's 
slow". Well, we all know it's relatively slow. But we might be less 
apprehensive if we think in terms of a tenth of a second for an isolated 
function. And if an isolated function or two starts slipping in, well, then 
it's a movement!

Tom Liotta