Not an easy problem to find Scott ford www.identityforge.com from my IPAD
> On May 10, 2014, at 2:18 AM, CM Poncelet <ponce...@bcs.org.uk> wrote: > > No, the ISV's updated code had assumed that a transaction's combination of > parms had to be either 'this' or 'that' etc. but had overlooked that it could > also be 'other' - which when true caused the ISV's code to loop back and try > again, forever ... and the online systems then froze because they were > getting no response from the ISV's application code (executing as a started > task). > > Scott Ford wrote: > >> What a random 1 byte overlay anywhere in storage? Collected on a bet on what >> it was .... >> >> Scott ford >> www.identityforge.com >> from my IPAD >> >> >> >> >> >>> On May 9, 2014, at 9:51 PM, CM Poncelet <ponce...@bcs.org.uk> wrote: >>> >>> Yes ... but there is a problem "of the third kind" where having the source >>> code would have been useful, as follows: >>> >>> 1. An ISV supplies 'calculating' software (running in a separate >>> address space) to which CICS online 4GL transactions pass >>> parameters using cross-memory services. The ISV's code then >>> processes these parms and returns the results of its calculations >>> to caller. The ISV also supplies weekly updates of its code, but >>> only as replacement LMODs. >>> 2. The ISV's latest update has a bug that makes it loop when a >>> combination of parms is passed to it. All the CICS systems then >>> freeze as they wait for a response. So we take system dumps of >>> the CICS regions and ISV's address space, and send them to the ISV. >>> 3. The ISV cannot determine what the problem is because the parms >>> are passed from 4GL 'code' in the dumps, but will not release the >>> source code either. The customer then has to restore the ISV's >>> previous LMODs in order to continue functioning, but at a cost >>> because the ISV's previous LMODs' calculations are no longer valid. >>> >>> My resolution was to put a GTF trace on all ASIDs, look for a recurring >>> pattern of CPU instruction addresses within a same ASID, identify the >>> begin/end addresses of the loop (and thus its offsets in the code), call >>> the ISV and tell them to bring their source code, recompile it with >>> whatever the Fortran assembler listing option was, check its assembly >>> offsets against those in the system trace, and tell the ISV which part of >>> their code needed to be fixed and why. (BTW This was in 1992.) >>> >>> So there is a "third kind" of problem when an ISV cannot fix yet will not >>> release its code and the ISV has not 'gone bust', because its source code >>> in escrow cannot then be accessed either. >>> >>> My ha'pennyworth. >>> >>> Chris Poncelet >>> IBM Systems Programming Consultant (retired) >>> Logic Integration Limited >>> >>> >>> R.S. wrote: >>> >>> >>>> W dniu 2014-05-09 13:35, John McKown pisze: >>>> >>>> >>>>> This has been an interesting thread. I rather like the escrow idea. >>>>> >>>> I consider it as useless. >>>> - Unclear reason to do it. Why source code in escrow would help the >>>> customer? >>>> - No warranty the code is complete, well documented and up to date. >>>> Without it can be useless for someone outside of ISV. >>>> - Skills. In order to use the code in any way some skills are required, >>>> possibly not available at customer. >>>> - Time. Any case when such code would be useful (assuming completness and >>>> skills) a significant time is need to perform any useful action, even >>>> simple first time recompilation could be long process. And the need to do >>>> it can be quite urgent. >>>> - Escrow trust. Both parties have to trust it. What about it the trust was >>>> disapointed? >>>> - Setlement of disputes. Who and WHEN should decide about customer's >>>> access to the code? It can be clear or not. Quick or not. >>>> >>>> >>>> >>>> BTW: There is quite another process - to buy the application with the >>>> source code, just to develop it further using own skills. In this case >>>> there is no escrow, and the code is actively used by custmer's development >>>> team, it's alive. >>>> >>>> >>>> >>>> My €0.02 >>>> >>>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
