Phil Smith III wrote:

>>Why 100? Is it documented somewhere in some REXX bookies?
>As I said, this isn't a Rexx API, but the point of 100 was to pick a human 
>number (not "666") that was way more than likely needed. We could have picked 
>5, but that seems low; 10? 20? 

Ok. I was just curious. Thanks.

>Hey, 100 oughta do it! (Like 640K, of course.)

Haha, that reminds me of that story that the micro$oft boss apparently said 
'640K is enough'. ;-)

>>Why not put all the parms in a file and then pass the file as an argument? 
>>Yes, I certainly know about [ unneeded ] overhead, I/Os, extra CPU cycles, 
>>memory, etc. of that alternative.

>Not practical. This API is typically called millions of times in rapid 
>succession, and it's atomic and stateless; we aren't going to read a parm file 
>every time. 

Ok. Good reason. When writing a program you need to consider all and everything 
and then you consider a method to pass arguments to/from a subroutine/function.

>And before someone says it, yes, if we do a Rexx version, I'd probably use 
>stemmed variables for the "list" version. OTOH, Rexx overhead is significant 
>enough that I'm not sure it would be used for large-scale operations, so it 
>might not even be worth the trouble-the "onesie" version would likely suffice.

Interpreted REXX overhead is really that bad. Yes, you can compile it for 
speed, but ...

In fact, during my career, I rewrote some heavily used REXX (and Clist) 
programs into a COBOL or Assembler version or arranged that a database language 
is used instead. 

Thanks Phil for stirring up this interesting thread.

Groete / Greetings
Elardus Engelbrecht

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to with the message: INFO IBM-MAIN

Reply via email to