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. > > 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
