I appreciate your help regarding what SDWARBAD represents I recall having an abend in a metal C program Which I linked to it may well have been running in supervisor state but it was a user Program I am just trying to just trying to determine the case where the abend happened in a supervisor state program which is not mine ( where I could of passed bad parameters or didn’t hold a required lock )
Since my program is erroneous it would be helpful to know what piece of my code called it Thanks > On Dec 5, 2020, at 9:45 AM, Peter Relson <[email protected]> wrote: > > Shmuel and Lennie and I took the time to provide the correct answer. You > apparently choose to ignore. Sad. > > SDWARBAD is valid only for supervisor state cases, as the comment says. > SDWANAME is never valid for that case. If a type 2/3/4 SVC routine blew > up, the RB address will be the address of the RB under which that routine > was running (which will be a newer RB than the RB that issued the SVC; it > is not necessarily the next-newer one for a case where the SVC routine > itself issued an SVC of some sort and that secondary SVC is what abended). > So you still need to find the RB that issued the SVC in order to see the > address of the issuer and the next-newer RB to see the regs at time of > issuance. If you issued a type 1 SVC, things are different. > > IBM would decline an RFE for providing the time-of-last-interrupt regs in > the SDWA which, at best are difficult to explain and use. You of course > are welcome to submit it. > We thought about the value of that when we designed 64-bit support. The > value was insufficient to warrant the cost (and extra storage usage -- and > yes that matters both in terms of just getting the storage and for having > room within the dump header). > > Peter Relson > z/OS Core Technology Design > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
