You may object "I can achieve exactly the same functionality as Mysay with an internal routine which is also much faster than your external mysay".
One might use the supplied macro USEMYSAY to convert a Rexx to call mysay(), but then go on to add an inline 'mysay' that might look like this:
Run my supplied test exec TINMYSAY ('IN' for 'Inline') to see an exec in action that uses code like this instead of the external 'mysay'.
The above simple 'mysay' substitute does indeed run very fast! The (supplied) panel 'scroller' picks up the pool variable 'dynamic1' and displays it. Of course, you haven't yet supplied a mechanism for the user to review the displays from a dsn after the run ... Neither have you provided for a status line, or a progress histogram of asterisks.
But the killer is this: What if one calls a low-level Rexx from this one? (Of course, one needs to convert the low-level Rexx with similar code to that above).
As soon as it displays its first inline 'mysay', the scrolling display in 'scroller' clears and begins filling afresh! You see this well displayed by running TINMYSAY.
If the top-level exec displays much output, and the low-level exec displays much output, this MAY be acceptable, not because it is a good design, but because you won't notice the fault in all that output.
But if either exec outputs only a few lines of 'mysay', the incessant clearing of the dynamic area defeats the whole purpose of a scrolling dynamic progress display.
I conclude that this is gospel: "factor your execs into units of functionality that do one thing and do it well" And if those execs display anything, then you need mysay() to be an external routine that communicates thru the pool (as external mysay does) and NOT have each exec manipulating a local version of 'dynamic1'
Of course, if Rexx allowed a global common block like PRIME Information then an inline solution would work fine. We could do a LOT of things in Rexx with that facility, but this is not the place to dwell on Rexx's shortcomings.