This would assume that the execs never fail, and leave the globalv variable
in place. If that should happen in a user's machine, it could be *very* hard
for them to debug, since they wouldn't technically know about the variable
in the first place, and probably wouldn't think of looking there for the
source of the problem.
And, they'd be even more frustrated when they logged off, came to your
office, logged back in, and everything worked correctly again.
Come to think of it, that might be a hoot! G'head and use the globalv! It's
so much fun laughing at users... :-D
--
.~. Robert P. Nix Mayo Foundation
/V\ RO-OE-5-55 200 First Street SW
/( )\ 507-284-0844 Rochester, MN 55905
^^-^^ -----
"In theory, theory and practice are the same, but
in practice, theory and practice are different."
On 12/27/07 8:09 PM, "Dale R. Smith" <[EMAIL PROTECTED]> wrote:
> In addition to the excellent suggestion of using a "secret" parameter or
>
> option in the calling Execs, you could also set a "secret" GLOBALV
> variable in the calling Execs and retrieve it in the called Exec. For
>
> example, EXECA and EXECB both call SUBEXEC:
> Code in EXECA and EXECB:
> Parse Source . . myname .
> 'GLOBALV SELECT SUBEXEC SET CALLEDBY' myname
> 'EXEC SUBEXEC parms (options'
> Code in SUBEXEC:
> 'GLOBALV SELECT SUBEXEC GET CALLEDBY'
> 'GLOBALV SELECT SUBEXEC SET CALLEDBY' /* Clear CALLEDBY Variable */
> If calledby = '' Then
> ... Called from Command Line
> Else
> ... Called from Other Exec
>
> An advantage to using GLOBALV is that you don't have to change your
> parameter/option parsing logic and if you need to know which Exec called
>
> SUBEXEC, then the calling Exec name is in "calledby".
