On 2020-05-25 17:04, Ed Jaffe wrote:
For the record, we diagnose issues using the events you've listed all
the time, no matter what the AMODE. In fact, we even have RMODE(64) code
nowadays.
There is a bug with 64-bit PTRACE formatting and we got a custom fix
from Jim Mulder for that (it will be GA with z/OS 2.5), but otherwise
everything we need is there.
What sort of information were you expecting that you did not see?
I probably painted with too broad a brush in my initial post, and for
that I apologize. The real offender is the PGM trace entry captured by
PI=56 in the GTF trace specification:
PGM..... 056 ASCB.... 00FBF880 CPU..... 0000 JOBN.... XXXXXXXX
OLD-PSW. 47543001 80000038 00000000 0149ADEE
TCB..... 008CBA08 VPH..... 7FFFF000 VPA..... 7FFFF800
MODN.... SVC-RES R0...... 84C85DFA R1...... 00FFF5FF
R2...... 7F6ADD38 R3...... 7F6ADE34 R4...... 80000050
R5...... 7F6ADCE5 R6...... 008C46D0 R7...... 008C46FC
R8...... 00000050 R9...... 84C85936 R10..... 01D9AE20
R11..... 008C4C68 R12..... 84C85936 R13..... 008C4010
R14..... 00000000 R15..... 7FFFF000
GMT-05/22/2020 14:40:47.514205 LOC-05/22/2020 10:40:47.514205
Despite being in AMODE 64, it only presents 32-bit registers. From
another source that I am prohibited by NDA from revealing, I know that
the entire contents of R15 were 7FFFF000_7FFFF000; I know that if the
problem was repeatable I could use SLIP (which does show register high
halves) to trace in the vicinity of the program check. But this would
have been immediately obvious if the GTF trace entry showed 64-bit
registers.
--
Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
