First, I would like to thank you for starting this thread.
I posted it to the performance people of my customer, and they told me, that
they just found a similar problem with EP PL/1 3.9, that is: the PLIMOVE
calls
don't generate MVCLs any more, as in previous releases, but series of MVCs
and loops. Even when the length of PLIMOVE is - for example - 8000 bytes.
They discovered it, because one of the PLIMOVE locations showed up in a
Strobe report.
I asked them to test using a ASSEMBLER program, if the MVC loop is faster,
but they told me, that even with lengths around 500 or 600, the MVCL
solution is faster
- this is on a z196. I have still to confirm this.
If this turns out to be true, this sounds like a bug, and we will try to
convince IBM to go back to
the previous solution. If we compile our modules during normal service
using EP PL/1 3.9,
our system will get slower and slower, because PLIMOVE is widely used.
This is not acceptable.
Because the PLIMOVEs are generated by a site-specific macro called PLICOPY,
I already thought about calling a short ASSEMBLER routine (with minimal
linkage conventions)
doing the transfer using MVCL instead of CALL PLIMOVE. The applications
need not
to be changed, because the PLICOPY syntax stays the same. Maybe this
could still be
faster than doing the MVC loop.
Kind regards
Bernd
Am 16.05.2012 19:05, schrieb Robert Prins:
On 2012-05-16 14:59, Paul Gilmartin wrote:
On Wed, 16 May 2012 07:55:48 -0600, Steve Comstock wrote:
Well, I knew someone would raise that exception. No,
Metal C does not use LE. Not sure if SP C (Systems
Programmer C) is still around and it would be an
exception too.
I believe it's been discussed in these fora that C and PL/I
share an optimizer/code generator. I hope this includes
Metal C. It's a long leap of logic, but that might weaken the
argument for LE entanglement. Is MOVE, BY NAME
plausibly dependent on LE?
For PL/I is is most definitely not, it's just a shortcut for lazy
people and I've worked at sites that explicitly forbade its use,
considering it just as bad as a "SELECT *" in SQL.
Robert
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
