Everyone's spot on: We're GMT+2 (stupid DST in Europe :-) ), so that explains why we didn't go through a time warp. :-)
Now, why am I not surprised that this verbx (I just wrote verby again!)ieavtsfs is a Jim-Mulder-Special? :-) Thank goodness it is there, though, and if you, Jim, want to fix something in a later release, that's fine. The blame lays squarely in my court, I guess. I wanted GRSQ(ALL) because we just had to merge two completely disparate sysplexes into one. They don't share anything except GRS Star, and I wanted to see any cross-system deadly embraces that may have been caused by our throwing together the RNLs of both sysplexes. I was quite unaware, though (or didn't read it properly because I didn't want to subconsciously), that GRS collection is a global exit. I would have sworn it is local. I just tested with grsq set to contention and the capture time decreased drastically. So let my scars be a warning to you! :-) Guess I need to say goodbye to that debugging help for the sake of 20s gain in production. (That means we can go back to q=yes, though!) And sorry that I just didn't put the timestamps into the post. Because system-wide non-disp was reported to be reset a few lines above, I assumed that everything below that line would be local, again. (Talk about making assumptions!) I realized later that the time stamp was actually inside the global non-disp window, and the exit address did the rest to make me feel guilty. I just looked at the dump task in the NDM address space. It must have been posted (link is 00), but the tcbflags say that the task is being swapped out. (Actually, all tasks are being swapped out.) I would have said that this is due to NDM running in discretionary, but I am not sure. SRM says that the address space is on the IN q, the WEB still pointing back to that SSRB has a DP of x'00C0 8000', while ASCBDPH=x'00C1'. ASCBEWST is (using another Jim-Mulder-Special, LISTTOD) 04/09/2008 15:04:43.107551, which is almost right at the beginning when the problem occured (15:04:43.048477). - There are a ton of global SRBs (that I didn't check, with 1.8 they're always there for a dynamic dump) and there is one local ssrb with a cpsw in ieavsrbs and RMTR=IEAVESPM. regs in the ssrb are all zero, and ptcb is the one that had the 0C4 in srb-to-task percolation for the original abend. Given my luck, the RT1W for that SRB is in use (my debugging teacher told me that I would never need to look at RT1Ws because they're never in use - I always get those that are) with a linkage stack entry for IEAVTSSD BAKR'ing to IEAVTSSM. That's summary dump processing, I think. Any more words of wisdom on this? (well, other than 'stupidity on the part of the OP :-) ? Best regards, Barbara -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ---------------------------------------------------------------------- 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
