The normal application dumps are normal business.
Once you know how to handle this - and you learn it best by teaching or
mentoring others - you can of course go further and solve more advanced
problems. A very hard problem for me was a race condition with two subtasks in
IBM's APL code (the linkage to other languages, processor 11). It took me weeks
to convince IBM that the error is in their code, not in ours, because they
couldn't reproduce it on their machines (our machines were faster, more CPUs).
They accepted it in the end when I did a local fix to their code and documented
in detail, what I made - I simply checked the ECB, and when finding the
condition that would lead to the subsequent ABEND, I waited for a little amount
of time, wrote a message, and then tried it again - and so the error
disappeared. But it took me weeks to find the reason for the problems and to
understand the code at the relevant positions - of course, it's all OCO.
IBM's APL code was patched on the fly, after initial load - control was
transferred from the original WAIT / POST routine to one of my own, that worked
a little bit different, see above.
In the end, IBM accepted my proposition for the remedy of this problem.
While working on this episode, it was very important for me that there was a
co-worker who was very experienced with all the z/OS topics and who encouraged
me to continue. He said to me things like that he already experienced problems
with APL in this particular area and he talked with me about my different
approaches and, although he did not support me with practical work, the
discussions with him were very helpful to me. Also some SLIP traces, because, as
you can imagine, the problem only occured once for some millions of
transactions, only during periods of peak load.
Am 30.07.2013 18:13, schrieb J.G.:
> There is no substitute for experience in the company of mentors/more
> knowledgeable colleagues. For this reason the very experienced,
> sure-footed mules who carry people down into and back up out of the
> Grand Canyon of the Colorado should not be consulted about the
> Canyon's geology.
> To vary the metaphor, books having titles like 'Topology made easy' or
> 'Neurosurgery for dummies' achieve their objectives, when they do, by
> leaving the hard parts out.