Good reasons why Mysay is an external routine.

Thesis :

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:

mysay : procedure expose dynamic1 parse arg p1 address ispexec if dynamic1 is too big to fit in 'scroller' dynamic area, dynamic1 = right(dynamic1,sizeof_area) 'control display lock' 'display panel(scroller)' return 0

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'.

My Response:

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.

Tracing is easier with an external 'mysay'

Tracing through a program which jumps to an inline 'mysay' is VERY distracting. You can put 'trace O' in the first executable line of the routine, but the constant jumps away from the code you are debugging interrupts the flow onscreen.
The external 'mysay' doesn't suffer from this problem.

The best reason of all:

External 'mysay' locates all the code (and all the bugs) in one place. When you fix a bug in 'mysay', you fix it in every program that relies on 'mysay'. When you fix a bug in inline code, the challenge of maintaining all the other clients is often worse than just putting up with the bug.