Variable Scoping considerations with GOSUB/COPY and SUBR.

This concept deals with variable values and memory as you branch into and
return from subroutines.  If you have a process that is using --- AI as a
counter and at some point in the code you branch into a subroutine and return,
the variable --- AI may have been changed (or stepped on) by the subroutine.
That is because GOSUBs and COPYs bring the code into the current process.
You can have the subroutine STORE and RESTORE any variables it uses, but that
only works one level deep.

If a subroutine is called by a GOSUB and it in turn calls another subroutine
with a GOSUB, then the STORE in the second subroutine will step on the STARE
done by the first subroutine.  This is because there is only one STORE/RESTORE
area per variable/process.

Example:

Process: TEST
SET      --- AI                 =     10
GOSUB    AAA DO SOMETHING
SET      --- BI                 = --- AI
*
END
*
LABEL    DO SOMETHING
STORE    --- AI
SET      --- AI                 =     20
GOSUB    AAA DO SOMETHING ELSE
RESTORE  --- AI
RETURN
*
LABEL    DO SOMETHING ELSE
STORE    --- AI
SET      --- AI                 =     30
RESTORE  --- AI
RETURN

So, instead of --- BI getting a value of 10, it would get a value of 30.  This
is because the second GOSUB'd routine wrote over the STORE buffer created by
the first routine.

On the other hand, if you use SUBR calls, then each SUBR routine contains it's
own STORE/RESTORE buffer area that can never step on the parent process
STORE/RESTORE buffer or be stepped on by any child process the SUBR calls.
This way, you are safe to use any variable as long as you STORE it first and
RESTORE it when done.  Process sharing characteristics are also handy for this.
If you call SUBRs as related, and SUBPROCESS variables are local and any
RELATED variables are shared.  This also allows for easy recursion.