Elardus Engelbrecht wrote: >It depends on the compiler of whatever language or underlying REXX interpreter environment like TSO. Can that many tuplets be handled/passed on to a function/subroutine?
Sure, and we hit the PL/I compiler limit of 384 arguments (there is a flavor that has two "things", but is otherwise the same; trust me, it's clear, not waiting for a disaster as in Charles' T/T/F/T/F/F example), so for PL/I, that call has a lower limit. >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? Hey, 100 oughta do it! (Like 640K, of course.) >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. This "list of things" API was, in fact, added to reduce the call overhead compared to the "one at a time" API, as that overhead becomes significant at that kind of scale. 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. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
