Re: Rexx performance question
Gentlemen, You're comparing apples and bananas. EXECOMM and GLOBALV are two distinc t namespaces. Further, there is one GLOBALV set of variables, whereas each REXX invocation has its own set of variables (and then there is PROCEDURE EXPOSE). j.
Re: Rexx performance question
John, I think the original post required a comparison of unlike items. It was a question of, Is there a faster way to pass environment variables from one EXEC to another? The method in use was GLOBALV and the poster wanted to know if there was a more efficient, faster, way to do it. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of John P. Hartmann Sent: Thursday, January 18, 2007 8:24 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Rexx performance question Gentlemen, You're comparing apples and bananas. EXECOMM and GLOBALV are two distinc= t namespaces. Further, there is one GLOBALV set of variables, whereas each= REXX invocation has its own set of variables (and then there is PROCEDURE= EXPOSE). j.
Re: Rexx performance question
And, EXECCOMM must be used by GLOBALV GET and PUT. Hence there is some relation performance wise. -- Kris Buelens, IBM Belgium, VM customer support 2007/1/18, Schuh, Richard [EMAIL PROTECTED]: John, I think the original post required a comparison of unlike items. It was a question of, Is there a faster way to pass environment variables from one EXEC to another? The method in use was GLOBALV and the poster wanted to know if there was a more efficient, faster, way to do it. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of John P. Hartmann Sent: Thursday, January 18, 2007 8:24 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Rexx performance question Gentlemen, You're comparing apples and bananas. EXECOMM and GLOBALV are two distinc= t namespaces. Further, there is one GLOBALV set of variables, whereas each= REXX invocation has its own set of variables (and then there is PROCEDURE= EXPOSE). j.
Re: Rexx performance question
On 1/18/07, Kris Buelens [EMAIL PROTECTED] wrote: And, EXECCOMM must be used by GLOBALV GET and PUT. Hence there is some relation performance wise. Ooh... Sir Kris disagrees with the Piper... ;-)You have any old passwords I can inherit? Rob
Re: Rexx performance question
I've lots of things to inherit. But, even now after this dangerous adventure, I think I have some chances to survive. When I rethink my will, I'll think to leave something for you Sir Rob, Yours truly, Sir Kris The Guide, The proud owner of an almost uncountable -and still growing, number of preciously kept passwords. 2007/1/18, Rob van der Heij [EMAIL PROTECTED]: On 1/18/07, Kris Buelens [EMAIL PROTECTED] wrote: And, EXECCOMM must be used by GLOBALV GET and PUT. Hence there is some relation performance wise. Ooh... Sir Kris disagrees with the Piper... ;-)You have any old passwords I can inherit? Rob
Re: Rexx performance question
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
Re: Rexx performance question
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
Rexx performance question
We have an old REXX exec that I had to modify. This is a rather simplistic description but it consists of 2 parts - 1 to set up the environment(variables) and 2 to use the variables setup in 1. Bottom I had problems modifying it so I re-wrote it. The original used GLOBALV extensively - part 1 would do PUTs and part 2 would do GETs. Besides a lot of 'steam lining' I thought I would be 'clever' and changed the GLOBALVs to 'PIPE var VarName 1 | var VarName'. However the new exec ran much slower than the old. I then did a test to only compare GLOBALV PUT/GET to setting and retrieving the variable with PIPE var stage. The pipe stage was much slower. I thought the pipe logic would be better - obviously mistaken. Any comments - any other method I could have used that is perhaps faster than GLOBALV? Thanks Peter
Re: Rexx performance question
No, I had not. Thanks, I will try. Kris Buelens [EMAIL PROTECTED] il.comTo Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: Rexx performance question 01/12/2007 10:23 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU Have you tried this too? PIPE LITERAL VAR1 VAR2 VAR3 ...| SPLIT |VARFETCH 1 DIRECT TOLOAD|VARLOAD DIRECT Note: the DIRECT tells not to try to resolve compound symbols, this also means one must pass the variable names in uppercase (and stem suffixes in the exact case). -- Kris Buelens, IBM Belgium, VM customer support 2007/1/12, Peter Rothman [EMAIL PROTECTED]: We have an old REXX exec that I had to modify. This is a rather simplistic description but it consists of 2 parts - 1 to set up the environment(variables) and 2 to use the variables setup in 1. Bottom I had problems modifying it so I re-wrote it. The original used GLOBALV extensively - part 1 would do PUTs and part 2 would do GETs. Besides a lot of 'steam lining' I thought I would be 'clever' and changed the GLOBALVs to 'PIPE var VarName 1 | var VarName'. However the new exec ran much slower than the old. I then did a test to only compare GLOBALV PUT/GET to setting and retrieving the variable with PIPE var stage. The pipe stage was much slower. I thought the pipe logic would be better - obviously mistaken. Any comments - any other method I could have used that is perhaps faster than GLOBALV? Thanks Peter
Re: Rexx performance question
From my testing, PIPES incur quite a bit of overhead when starting up. So, optimising means doing as much as possible within a PIPE to amortise that overhead over as much work as possible, and therefore using as few PIPE instances as possible. You could write the variables to a temporary disk file as well. But use EXECIO instead of PIPES to write the file, it uses less resources for small files. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Peter Rothman Sent: January 12, 2007 10:55 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Rexx performance question Tested that - also much slower than GLOBALV. Kris Buelens [EMAIL PROTECTED] il.com To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: Rexx performance question 01/12/2007 10:23 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU Have you tried this too? PIPE LITERAL VAR1 VAR2 VAR3 ...| SPLIT |VARFETCH 1 DIRECT TOLOAD|VARLOAD DIRECT Note: the DIRECT tells not to try to resolve compound symbols, this also means one must pass the variable names in uppercase (and stem suffixes in the exact case). -- Kris Buelens, IBM Belgium, VM customer support 2007/1/12, Peter Rothman [EMAIL PROTECTED]: We have an old REXX exec that I had to modify. This is a rather simplistic description but it consists of 2 parts - 1 to set up the environment(variables) and 2 to use the variables setup in 1. Bottom I had problems modifying it so I re-wrote it. The original used GLOBALV extensively - part 1 would do PUTs and part 2 would do GETs. Besides a lot of 'steam lining' I thought I would be 'clever' and changed the GLOBALVs to 'PIPE var VarName 1 | var VarName'. However the new exec ran much slower than the old. I then did a test to only compare GLOBALV PUT/GET to setting and retrieving the variable with PIPE var stage. The pipe stage was much slower. I thought the pipe logic would be better - obviously mistaken. Any comments - any other method I could have used that is perhaps faster than GLOBALV? Thanks Peter The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot by guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner.
Re: Rexx performance question
Using a file to store the variables a while, uggghhh... File I/O remains terribly slow compared to memory access, even though you might save some CPU (I don't know if you will save) the result may be code than takes longer to complete in elapsed time. The fact that EXECIO is faster than PIPE to write files is that one often sees execs that every now and then write to a file. If you do that with PIPE, the file is closed after each write request; with EXECIO, the file is only closed when you explicitly ask for it. Again, the general rule is: do as much as possible in a single call, to PIPE, to XEDIt, to 2007/1/12, [EMAIL PROTECTED] [EMAIL PROTECTED]: From my testing, PIPES incur quite a bit of overhead when starting up. So, optimising means doing as much as possible within a PIPE to amortise that overhead over as much work as possible, and therefore using as few PIPE instances as possible. You could write the variables to a temporary disk file as well. But use EXECIO instead of PIPES to write the file, it uses less resources for small files. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Peter Rothman Sent: January 12, 2007 10:55 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Rexx performance question Tested that - also much slower than GLOBALV. Kris Buelens [EMAIL PROTECTED] il.com To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: Rexx performance question 01/12/2007 10:23 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU Have you tried this too? PIPE LITERAL VAR1 VAR2 VAR3 ...| SPLIT |VARFETCH 1 DIRECT TOLOAD|VARLOAD DIRECT Note: the DIRECT tells not to try to resolve compound symbols, this also means one must pass the variable names in uppercase (and stem suffixes in the exact case). -- Kris Buelens, IBM Belgium, VM customer support 2007/1/12, Peter Rothman [EMAIL PROTECTED]: We have an old REXX exec that I had to modify. This is a rather simplistic description but it consists of 2 parts - 1 to set up the environment(variables) and 2 to use the variables setup in 1. Bottom I had problems modifying it so I re-wrote it. The original used GLOBALV extensively - part 1 would do PUTs and part 2 would do GETs. Besides a lot of 'steam lining' I thought I would be 'clever' and changed the GLOBALVs to 'PIPE var VarName 1 | var VarName'. However the new exec ran much slower than the old. I then did a test to only compare GLOBALV PUT/GET to setting and retrieving the variable with PIPE var stage. The pipe stage was much slower. I thought the pipe logic would be better - obviously mistaken. Any comments - any other method I could have used that is perhaps faster than GLOBALV? Thanks Peter The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot by guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner. -- Kris Buelens, IBM Belgium, VM customer support
Re: Rexx performance question
Why not define a vdisk for storing the variables? Definitely faster than the real thing. Steve G Kris Buelens [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 01/12/2007 11:38 AM Please respond to The IBM z/VM Operating System To: IBMVM@LISTSERV.UARK.EDU cc: Subject:Re: Rexx performance question Using a file to store the variables a while, uggghhh... File I/O remains terribly slow compared to memory access, even though you might save some CPU (I don't know if you will save) the result may be code than takes longer to complete in elapsed time. The fact that EXECIO is faster than PIPE to write files is that one often sees execs that every now and then write to a file. If you do that with PIPE, the file is closed after each write request; with EXECIO, the file is only closed when you explicitly ask for it. Again, the general rule is: do as much as possible in a single call, to PIPE, to XEDIt, to 2007/1/12, [EMAIL PROTECTED] [EMAIL PROTECTED]: From my testing, PIPES incur quite a bit of overhead when starting up. So, optimising means doing as much as possible within a PIPE to amortise that overhead over as much work as possible, and therefore using as few PIPE instances as possible. You could write the variables to a temporary disk file as well. But use EXECIO instead of PIPES to write the file, it uses less resources for small files. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU ] On Behalf Of Peter Rothman Sent: January 12, 2007 10:55 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Rexx performance question Tested that - also much slower than GLOBALV. Kris Buelens [EMAIL PROTECTED] il.com To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: Rexx performance question 01/12/2007 10:23 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU Have you tried this too? PIPE LITERAL VAR1 VAR2 VAR3 ...| SPLIT |VARFETCH 1 DIRECT TOLOAD|VARLOAD DIRECT Note: the DIRECT tells not to try to resolve compound symbols, this also means one must pass the variable names in uppercase (and stem suffixes in the exact case). -- Kris Buelens, IBM Belgium, VM customer support 2007/1/12, Peter Rothman [EMAIL PROTECTED]: We have an old REXX exec that I had to modify. This is a rather simplistic description but it consists of 2 parts - 1 to set up the environment(variables) and 2 to use the variables setup in 1. Bottom I had problems modifying it so I re-wrote it. The original used GLOBALV extensively - part 1 would do PUTs and part 2 would do GETs. Besides a lot of 'steam lining' I thought I would be 'clever' and changed the GLOBALVs to 'PIPE var VarName 1 | var VarName'. However the new exec ran much slower than the old. I then did a test to only compare GLOBALV PUT/GET to setting and retrieving the variable with PIPE var stage. The pipe stage was much slower. I thought the pipe logic would be better - obviously mistaken. Any comments - any other method I could have used that is perhaps faster than GLOBALV? Thanks Peter The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot by guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner. -- Kris Buelens, IBM Belgium, VM customer support
Re: Rexx performance question
What is wrong with using GLOBALV? That can be memory-only as indicated in the original post (it specified GET and PUT, not GETS, GETP, PUTS or PUTP). There is no need to write to disk unless you need for the variables to be retained across IPLs or logons (SESSION or LASTING GLOBALV). Since it is strictly memory access, it ought to be faster than using either Pipe or EXECIO. However, it might be faster if the two EXECs could be joined together in a single EXEC so that the environment variables would already be there and not need to be passed to the EXEC that uses them. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Steve Gentry Sent: Friday, January 12, 2007 10:02 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Rexx performance question Why not define a vdisk for storing the variables? Definitely faster than the real thing. Steve G
Re: Rexx performance question
Even a VDISK means lots of overhead: one needs to go down all the way to CP. If variables are more/or less constant, one can store them in a CMS file, directly in a format understood by the VARLOAD stage. /varname/contents... Then one can EXECLOAD that file and code PIPE MYVARS FILE |VARLOAD DIRECT Note that you cannot code a filemode on the stage, the absence of a filemode tells PIPE to look for an EXECLOADed file first. 2007/1/12, Steve Gentry [EMAIL PROTECTED]: Why not define a vdisk for storing the variables? Definitely faster than the real thing. Steve G *Kris Buelens [EMAIL PROTECTED]* Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 01/12/2007 11:38 AM Please respond to The IBM z/VM Operating System To:IBMVM@LISTSERV.UARK.EDU cc: Subject:Re: Rexx performance question Using a file to store the variables a while, uggghhh... File I/O remains terribly slow compared to memory access, even though you might save some CPU (I don't know if you will save) the result may be code than takes longer to complete in elapsed time. The fact that EXECIO is faster than PIPE to write files is that one often sees execs that every now and then write to a file. If you do that with PIPE, the file is closed after each write request; with EXECIO, the file is only closed when you explicitly ask for it. Again, the general rule is: do as much as possible in a single call, to PIPE, to XEDIt, to 2007/1/12, [EMAIL PROTECTED] [EMAIL PROTECTED] * [EMAIL PROTECTED][EMAIL PROTECTED] : From my testing, PIPES incur quite a bit of overhead when starting up. So, optimising means doing as much as possible within a PIPE to amortise that overhead over as much work as possible, and therefore using as few PIPE instances as possible. You could write the variables to a temporary disk file as well. But use EXECIO instead of PIPES to write the file, it uses less resources for small files. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] *IBMVM@LISTSERV.UARK.EDU] On Behalf Of Peter Rothman Sent: January 12, 2007 10:55 To: [EMAIL PROTECTED] IBMVM@LISTSERV.UARK.EDU Subject: Re: Rexx performance question Tested that - also much slower than GLOBALV. Kris Buelens [EMAIL PROTECTED] *il.com* http://il.com/ To Sent by: The IBM [EMAIL PROTECTED]IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] * [EMAIL PROTECTED] Subject *ARK.EDU* http://ark.edu/ Re: Rexx performance question 01/12/2007 10:23 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] [EMAIL PROTECTED] *ARK.EDU* http://ark.edu/ Have you tried this too? PIPE LITERAL VAR1 VAR2 VAR3 ...| SPLIT |VARFETCH 1 DIRECT TOLOAD|VARLOAD DIRECT Note: the DIRECT tells not to try to resolve compound symbols, this also means one must pass the variable names in uppercase (and stem suffixes in the exact case). -- Kris Buelens, IBM Belgium, VM customer support 2007/1/12, Peter Rothman [EMAIL PROTECTED][EMAIL PROTECTED] : We have an old REXX exec that I had to modify. This is a rather simplistic description but it consists of 2 parts - 1 to set up the environment(variables) and 2 to use the variables setup in 1. Bottom I had problems modifying it so I re-wrote it. The original used GLOBALV extensively - part 1 would do PUTs and part 2 would do GETs. Besides a lot of 'steam lining' I thought I would be 'clever' and changed the GLOBALVs to 'PIPE var VarName 1 | var VarName'. However the new exec ran much slower than the old. I then did a test to only compare GLOBALV PUT/GET to setting and retrieving the variable with PIPE var stage. The pipe stage was much slower. I thought the pipe logic would be better - obviously mistaken. Any comments - any other method I could have used that is perhaps faster than GLOBALV? Thanks Peter The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot by guaranteed on the Internet. The Sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail
Re: Rexx performance question
We have not heard from Michael Coffin on this subject. IIRC he was very knowledgeable about using GLOBAL variables in REXX code. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Friday, January 12, 2007 1:44 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Rexx performance question What is wrong with using GLOBALV? That can be memory-only as indicated in the original post (it specified GET and PUT, not GETS, GETP, PUTS or PUTP). There is no need to write to disk unless you need for the variables to be retained across IPLs or logons (SESSION or LASTING GLOBALV). Since it is strictly memory access, it ought to be faster than using either Pipe or EXECIO. However, it might be faster if the two EXECs could be joined together in a single EXEC so that the environment variables would already be there and not need to be passed to the EXEC that uses them. Regards, Richard Schuh _ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Steve Gentry Sent: Friday, January 12, 2007 10:02 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Rexx performance question Why not define a vdisk for storing the variables? Definitely faster than the real thing. Steve G If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
Re: Rexx performance question
I'd say there's nothing wrong with GLOBALV, but plumbers use their Piping tools. GLOBALV has an extra advantage: it is clear to the reader when one shares variables between execs. With a PIPE in a called exec one can do anything that the reader of the calling exec will not be aware off. Something more I remember: when REXX's VALUE function was extended to support GLOBAL variables, we were told that using VALUE() was faster than the GLOBLAV command. But, only when compared to GLOABLV with a single variable, so 'GLOBALV GET V1 V2 V3' outperforms 3 calls to VALUE(). -- Kris Buelens, IBM Belgium, VM customer support 2007/1/12, Stracka, James (GTI) [EMAIL PROTECTED]: We have not heard from Michael Coffin on this subject. IIRC he was very knowledgeable about using GLOBAL variables in REXX code. -Original Message- *From:* The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] *On Behalf Of *Schuh, Richard *Sent:* Friday, January 12, 2007 1:44 PM *To:* IBMVM@LISTSERV.UARK.EDU *Subject:* Re: Rexx performance question What is wrong with using GLOBALV? That can be memory-only as indicated in the original post (it specified GET and PUT, not GETS, GETP, PUTS or PUTP). There is no need to write to disk unless you need for the variables to be retained across IPLs or logons (SESSION or LASTING GLOBALV). Since it is strictly memory access, it ought to be faster than using either Pipe or EXECIO. However, it might be faster if the two EXECs could be joined together in a single EXEC so that the environment variables would already be there and not need to be passed to the EXEC that uses them. Regards, Richard Schuh
