Barbara/Tom/Tony/Jim,
Thanks for your help on this.
I did indeed get a SPER trace entry, which indicated I wasn't on the waiting
CPU at all. That also showed up another invalid assumption I'd made, that the
time on the STATUS command would be close to the time of the SPER. it wasn't
it's was 8 seconds later.
My slip fired within 0.00002 sec of the PC call. The apparent delay was
because, by the time of the dump capture, the control blocks had been freed
and re-used, possibly several times. My 2nd STCK value was for a different
user/request.
Unfortunatly this is a very multi tasking DBMS environment. As well as about a
dozen different TCBs we also have up to several hundred SRBs waiting for work
on zIIP(s) and several hundred external users PCing into the address space to
schedule work with wait/post onto an SRB or TCB. I believe the LPAR has 6
processors and at least a couple of zIIPs. By the time the dump happens we've
processed several thousand more DBMS requests.
Bottom line is that by the time we get the dump things have moved on to the
point where all my traces have wrapped and all relevent info has gone. I've
had a look at using SYNCSVC but I think this will only stop one of the several
thousand requests comming in per second.
I don't think there is any way to stop the whole AS for the duration of the
dump capture?
Ron.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
