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. This
disclaimer is the property of the TTC and must not be altered or circumven!
ted in any manner.
--
Kris Buelens,
IBM Belgium, VM customer support
--
Kris Buelens,
IBM Belgium, VM customer support
