RE: prob- reverse a string in cl

[qsrvbas@xxxxxxxxxxxx]

midrange-l-request@xxxxxxxxxxxx wrote:

>   6. Re: prob- reverse a string in cl (vhamberg)
>
>But I have to admit to being a little stuck in the CL-RPG world of compiled 
>languages. You are nudging me a bit, and I want to explore further. Doing 
>STRREXPRC _repeatedly_ from a CL is a losing proposition, however - have tried 
>it, a real dog. But that is probably not the best use of it, as you showed.
>

Vern:

There's no doubt that REXX can slow procedures significantly, most certainly 
when called repeatedly. But it might not make a difference in many 
circumstances.

I ran a quick test on a small 270 at V5R1 to see what kind of penalty we're 
talking about -- 1000 executions of the REXX proc to reverse a string ran in 
110 wall-seconds. Pretty bad in comparison, but it depends on what's expected I 
suppose.

The actual test was 1000 CALLs of a CLP that called the REXX reversal proc 
passing in the string, then pulled the result back off of the REXX queue. The 
REXX proc always cleared the queue to start and also included all of the basic 
SIGNAL statements and procedures to display the common errors that REXX might 
encounter. If it were stripped to only its functional statements, it might run 
a little quicker. So, the outer CLP called the inner CLP 1000 times; and they 
were CLPs, not ILE CL.

The inner CLP created an argument string that prepended the two-byte length to 
the argument string for the REXX proc, always checking the right-trimmed length 
first even though it was the same string over and over. That would've added a 
small amount of time. This was done because REXX was called by using the QREXX 
API rather than the STRREXPRC command.

On average, then, the turnaround time was a tenth of a second or so, including 
overhead. I think the biggest hit is the first time a proc is called, sort of 
like the initial overhead of creating an activation group but magnified.

There is at least one interesting aspect since REXX is always available 
(assuming authority)...

The REXX procedure can be generated on the fly. Create a temp source file and 
stick a temp member in it. Then execute it. And since REXX procedures can 
execute dynamic REXX statements with the INTERPRET statement, you can have a 
fairly simple REXX that pulls statements off of the REXX queue and executes 
them. ...IOW, a different procedure every time if you wish.

REXX is very interesting.

Tom Liotta

>-------------- Original message -------------- 
>From: "Dave Odom" <Dave.Odom> 
>
>> Vern & Scott, 
>> 
>-snip-
>> 
>> Vern, 
>> 
>> Wasn't suggesting using CL at all. Perhaps I didn't understand the 
>> whole picture but didn't see CL in the picture. Since I don't usually 
>> CALL REXX from CL or the other way round, I don't see the overhead. 
>> Perhaps I'll have to give it a try sometime. 
>> 
>> I do whatever I can in REXX because its more powerful, simpler and the 
>> development turn around is quicker than other System i5 languages since 
>> there is no compiling, just code and run using PDM. If it doesn't work, 
>> you see your mistakes on your screen; no looking in a job log in most 
>> cases. Hit enter, edit the file again, make your changes, F3 out and 
>> 16 and see if it works. 
>> 
>> Not saying REXX is the end-all, be-all but haven't found much I can't 
>> do on the System i5 yet and the performance is great. Plus you can use 
>> the skill on other IBM platforms since its an SAA language. Plus, since 
>> REXX is sorta-kinda like other modern free form languages, if you know 
>> REXX, your transition to those other modern free form languages (good 
>> for your resume) won't be as great a leap as from CL or RPG. I've seen 
>> entire apps, (IIRC, an example is IBMs time card system (TOTALS), done 
>> in REXX, running on VM. However, they may have moved it to a different 
>> platform now. I've programmed in many languages, even RPG, but like to 
>> use non-esoteric and cross-platform tools if at all possible. 
>> 
>> Now, I'll admit, if I was doing a large app like A/R, A/P, CRM, 
>> manufacturing shop floor control, inventory, etc. I'd use a compiled 
>> language where ever possible.