> Without seeing the dump, I would guess that someone did a GTRACE > which specified a DATA address of zero (at offset 4 in the GTRACE parm > list). > In that case, AHLTUSR will think that DATA64 was specified, > and treat whatever is at offset 8 in the GTRACE parm list as a 64-bit data > address. > > Effectively, the DATA64 support in GTRACE makes it so that you > can't trace a data starting at address 00000000 using the > DATA parameter. If you really want to trace address 0 > (which isn't of much use), you need to use DATA64 with address > 0000000000000000.
Thanks a lot, Jim. I have forwarded this to the person owning that gtrace code. I believe this is an invocation problem, but without source code ..... (Also, in all of my debugging career, this was the first time I had to look into a dump in gtf code.) > Note that GTF is dumping and terminating in this case because > DEBUG=YES is specified in the PARM= in the GTF proc. Without > DEBUG=YES, AHLTUSR's FRR will just retry without tracing > anything, and without dumping, and GTF will not terminate. Yes, I am taking the default as delivered by the ADCD system. Unfortunately, the control block that gets traced in that invocation is one that is needed for debugging the original problem. (R6 + change was pointing to that control block). Best regards, Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
