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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
