For example, let's say that you pass a RAM script to RexxStart(). You receive back the tokenized version. Now, you want to alter that script in RAM and run the new version. Upon some interpreters, if you then pass the new script back to RexxStart() using the same RXSTRING array that already contains the tokenized version of the old script, you may get the old script running. (ie, The script isn't re-tokenized). So, you either have to use a different array of RXSTRINGs, or zero out the strptr of that second RXSTRING.
Plus, if you try to use the same name for two different REXX scripts in RAM, you may be asking for problems with certain interpreters. Some won't let you use the same name for two different scripts. You may even get problems when you alter a RAM script, and use a different array of RXSTRINGs to re-tokenize it, but retain the same script name. This may be considered an instance of two different scripts with the same name. So, it may be difficult to update a script after it has been added to the macro table, unless you rename it.
What about the buffer containing that tokenized version of the script? Who allocated it? The REXX interpreter. Who is responsible for freeing it? Well, that was never standardized. Theoretically, you are supposed to do that, but just like with freeing any return value from the script, there was never a standard for how you should free it. You really should use RexxFreeMemory(), but as mentioned before, some interpreters don't support that, and instead expect you to use some OS function.
And there are inevitably some resources consumed by the interpreter when it adds a script to its internal macro table. These resources won't be freed until your program ends. So, that means that if you launch a lot of scripts from RAM, you'll end up using a lot of memory inside the interpreter which won't be freed until your program ends. Even if you end up executing a given script in RAM only once, it continues hanging around in the interpreter's internal macro table until your program ends.
And in some interpreters, a script can tap into the macro table. That is -- when a script calls another script, the interpreter first searches its internal table for one with that name (as opposed to first looking on disk). So if a REXX script happens to call another script that has the same name as your script in RAM, then your RAM script gets executed. So, it could be a problem to indiscrimately leave RAM scripts in the interpreter's internal macro table.
Without the ability to be able to query/delete macros from the interpreter's table, there are a lot of problems here. Reginald offers some extensions to RexxStart() to query internal macros by name, and delete them from Reginald's internal macro table. And there is a RexxMacroXXX API that was later added to some REXX interpreters to do the same. But it's really hit or miss as far as implementation is concerned. It is best to be sparing when executing scripts from RAM, or use extensions such as Reginald's (described later) to help "clean up" the interpreter's macro table while your program is running and avoid the problems cited above.
Some interpreters use case-sensitive names for their macros, and others don't. So, if you want to use different names for your macros, always assume that there is no difference with regard to case (ie, "BLORT" is the same as "blort").