The GLOBALV solution often also requires two calls to EXECCOMM:
GLOBALV PUT in the calling exec and GLOBALV GET in the callee
If the variables contain one word only, one can indeed save a call to
EXECCOM:
'GLOBALV SET V1' content 'V2' content ....
But, in such cases one can also pass the variables as arguments to the
callee. In my PRFGUI package, this technique is extensively used. The
caller:
'EXEC PRFGD PLOT' files ',',
WorkWithTrd Spec407Bug UserVarsFnd NodeVarsFnd TracePipe chartid',',
DtStringFromCharPtr DtStringToBuffer DtStringAppend DtObjectDelete,
DtEventNotify DtValueSet DtValueGet DtTableCount DtTableQuery,
hCnChanClo hCnChanRun hCnEdChMsg hCnEdChMsgC hCnLyChan',',
Days2plot red cyan cyan2 yellow yellow2 gddmSticky,
',' hCnLsFlDisa,
....
Note that I insert some separator character (a comma above) when a
preceeding variable can be empty or when the contents can be more than 1
word. Needless to say that the corresponding PARSE ARG in the callee must
have an indentical template.
--
Kris Buelens,
IBM Belgium, VM customer support
2007/1/13, Rob van der Heij <[EMAIL PROTECTED]>:
On 1/12/07, Peter Rothman <[EMAIL PROTECTED]> wrote:
> Besides a lot of 'steam lining' I thought I would be 'clever' and
changed
> the GLOBALVs to 'PIPE var VarName 1 | var VarName'.
The EXECCOMM interface is known to be slow. With GLOBALV you only use
it once to set the variable, with the Pipeline you need 2 for the same
thing. I would expect that to be slow.
Depending on the number of Rexx variables present and involved, you
may gain back some performance using 'rexxvars' to retrieve all
variables and have a 'lookup' stage select the ones to use.
If there's enough variables to copy that this makes a difference, then
I assume they contain the data your subroutine works on. It is often
not hard to make the subroutine in a pipe stage and pass the data
through the pipeline rather than the Rexx variables.
But the most efficient approach is of course to keep the data in the
pipeline entirely.
Rob
