Dumps are snapshots and you're trying to debug a process. So unless the process is recorded in the trace table entries available in the dump all
the dump tells you is - yep, there's a problem with that counter. If it were me I'd want to first make sure that the relevent events are creating trace table entries - if not, either use TRSOURCE or add code to create the trace table entries. Then, use TRSAVE to write the trace entries to tape until the problem happens. After that it's just a data reduction problem. ;) A long time ago I had a modification to CP that would timestamp the trace table entries. Now-a-days, trace table entries contain the time-of-day clock value. The other alternative is to have intimate knowledge of the process and debug it from the logic end with the source code. Not always a reliable process and frequently requires adding code to get the some debugging information - which is exactly what the trace table is for. See above. Brian Nielsen "It's only ones and zeroes" On Wed, 24 May 2006 15:34:10 -0700, Schuh, Richard <[EMAIL PROTECTED]> wrot e: >It is difficult to be too helpful with a problem that even the vendor cannot solve after having been provided several dumps ;-) I speak of user s hung in LOGOFF/FORCE PENDING status with a deferred work count of 2 and nothing in the queue. If you can find some way to determine whether it is the result of a process that increments the count without putting anythin g on the queue or one that fails to decrement the count when it has completed, please let me know. You get extra credit if you can figure out a way to determine how long the count has been bogus. > >Regards, >Richard Schuh > > -----Original Message----- >From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark >Sent: Wednesday, May 24, 2006 3:15 PM >To: [email protected] >Subject: Re: GIVE command on a tape drive with intervention required > >On Wednesday, 05/24/2006 at 01:37 EST, Brian Nielsen ><[EMAIL PROTECTED]> wrote: >> I've run some traces and know why DDR is abending. If you don't want to >> read the technical details below, the question is: Is this an APAR'abl e >> DDR problem or "user error caused by the HALT - don't do that"? > >Please open a PMR, Brian. Because you asked so nicely ["he's such a >*nice* boy"] and you have such helpful problem determination skills, we're >inclined to treat it initially as a bug. (And I'm not 100% certain, but I >think it helps that the developer is also named Brian.] > >But I ask you, why can't everyone else include a nice detailed analysis of >the problem in *their* problem descriptions? I mean, it's not like in >some alien language like Java or C++! ;-) [OCO modules excluded, of >course] > >Alan Altmark >z/VM Development >IBM Endicott >======================== ========================= =======================
