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 <[email protected]> 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 [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



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to