I recall in 1988 having some software step on an idcams control block that was part of chain that dynamically grew and shrunk depending on how the dataset was accessed. It only happened about every three months and by the time the traps were fine-tuned to catch it, the software was all replaced and it stopped happening.
In the case of a changing data structure being overwritten by defective code, if the problem cannot be reproduced it can be very difficult to diagnose. On 12/13/07, Barbara Nitz <[EMAIL PROTECTED]> wrote: > > Quote from the diagnosis book: > > "It is easier for IBM Service to solve a problem when a test case is > available. Include a test case with your problem report wherever possible." > > This really rubs me the wrong way, not because it isn't true, but because > to me it sounds like justification why these highly intermittend, > non-reproducible problems are never found! To someone used to z/OS and > finding the bug with the one and only dump ever produced (because it is a > serialization problem of some sort, possibly caused by the fact that > multiple processors can execute the same instruction at exactly the same > time), this sounds like an excuse, proven by the way these problems are > always handled, due to lack of skill and knowledge.. > > <rant off> > Barbara > -- > Psssst! Schon vom neuen GMX MultiMessenger gehört? > Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
