On Mar 19, 2016, at 11:04 PM, Joel C. Ewing wrote:
On 03/19/2016 03:13 PM, Ed Gould wrote:
On Mar 19, 2016, at 2:42 PM, Joel C. Ewing wrote:
On 03/18/2016 11:14 PM, Ed Gould wrote:
On Mar 18, 2016, at 1:00 PM, Clark Morris wrote:
On 18 Mar 2016 07:27:09 -0700, in bit.listserv.ibm-main Itschak
wrote:
no recompile involved. Just relink to replace IBM's LE modules.
So what processor(s) is this code running on? What exactly is
being
done?
Clark Morris
--------------SNIP----------------------------
So ... how do you know when an LE module changes?
Manual effort?
Ed
I'm pretty sure he means re-link to replace any IBM-licensed LE
modules
within application load modules with non-IBM functional replacement
modules that are either part of or interface to whatever replaces
the LE
run time in the new environment. If that is successful, the
resulting
load module is no longer associated with IBM's LE and you could care
less if IBM makes subsequent LE changes. In the unlikely event that
fixes/enhancements to the LzLabs run time environment might have
versioning issues that require re-linking to change their interface
modules at some later time, that would be an issue independent
from any
changes in IBM's LE.
I may have missed something in the thread. However,
When you get a mixed LE module (PTF type) level all bets are off when
it comes to LE. Execution platform comes with its own issues and
complicates debugging beyond anything I would be willing to support
and I suspect other on here would have the same issues.
At one time Amdahl had issues and with the coming of OCO came the
demise and I suspect IBM saw (caused) the issue as well.
I suspect any OEM would have similar issues without source. IIRC some
modules are semi public source available in JES2 although some
modules in JES2 are OCO. I don't know about JES3 but I suspect its
close to being the same.
LE is an example of all OCO and seeing as they (LE) can't get their
act together any other vendor IMO would be stupid if they think they
can emulate LE .
Ed
Unless he relinks the module(s) to pick up any changed LE modules
each
time maintenance is applied he will be in for a big surprise.
LE is *KNOWN* for changing the rules without telling anyone. LE is
the
*WORST* IBM product ever delivered, IMO.
Ed
Ed,
As I understand it, in a context where there would be NO IBM LE
modules,
your comment simply doesn't make sense: the context being executing
legacy mainframe application object code on non-mainframe hardware,
in a
non-IBM operating environment that has NO IBM run time libraries or
code, an environment that supposedly runs application load modules
designed for CICS and batch environments by replicating the
functionality of application interfaces that would be needed by such
load modules previously generated by COBOL and PL/I compilers for
those environments.
Surely a customer owns the rights to object modules generated by
compiling customer source code, but just as surely IBM owns the rights
to any modules generated solely from IBM source code. The LE run time
environment is part of IBM's licensed code on z/OS. Unless you
believe
IBM is going to reverse its Hercules policy and start licensing IBM
software to run in non-IBM-sanctioned hardware environments, that
means
the LzLabs implementation must not depend on an IBM LE modules or any
other IBM code for providing LE-like functionality in its execution
environment, and any IBM code modules that were linked into the
application load modules for run time support would likely need to be
functionally replaced to legally run the application under an LzLabs
environment. Dynamic linking to IBM LE run time library routines
would
also be unavailable. We are talking here about an environment to
execute functionally-frozen mainframe application code -- there are no
claims of support for application development or use of COBOL and PL/I
compilers under LzLabs.
Once an application successfully makes the jump to the LZLabs
environment, that of necessity means it is no longer running any LE or
other IBM restricted-license code and that all LE-like functionality
provided by LzLabs code at the time of that jump must be compatible
with
what the application load module needs. IT MAKES NO DIFFERENCE AFTER
THAT POINT IF IBM CHANGES ANY LE CODE OR ANY OF THE RULES FOR LE OR
FOR
THE IBM COMPILERS. The old application modules under LzLabs are
unchanged so their requirements that are being satisfied by LzLabs
code
are also unchanged. The stable application load module is at that
point running in the LzLabs environment with the IBM LE run time
environment code and IBM COBOL and PL/I compilers totally out of the
picture!
Whether LzLabs can successfully provide the claimed support, and
whether
they can do it without some illegal reverse engineering and without
violation of IBM patents or other intellectual property rights are
separate issues beyond my skill set.
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
