Thanks for the explanations, and suggestions. What I was observing, even if it was residual data, seemed different, either for v1.11 itself, or some other component added last year to our systems in support of v1.11.
I had not been successful with a SLIP, earlier, but I was able to observe the TCBCMP fields of the INIT tasks using Mainview and I was able to see that certain batch jobs caused this field to change, on a fresh initiator, with the first execution of a batch job, so I set a SLIP to the ASID of the INIT and obtained a LOGREC, and set another SLIP to get a full DUMP. There really is a s0C4 in module PRS30610 at the 06/23/10 10.23 assembly level, reg6 is bad, and the INIT task recovers, and except for the residual data (and the overhead of processing the interrupt, etc.), no one is the wiser. PRS30610 is intercepting a dynamic allocation out of IGGDADSM. PRS30610 is part of Mainview SRM, which used at both sites whose dumps showed this INIT TCBCMP s0c4. I will take this problem to the vendor (severity level 4). regards, Joe D'Alessandro ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
