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