The C header has all that. cib_machine from the __cib structure is the pointer to the machine block. __mch has the psw, regs and bear at the time of abend. This all assumes you are running TRAP(ON).
In article <54c1508e.3050...@t-online.de> you wrote: > Hello Charles, > I hope that I am not directing you in the wrong direction ... that is: > I hope that the CIB that you see contains the information that you need. > What we did at the recent site that I worked: we had a LE exit that > got control at all exceptions - no matter what kind - and did all the > error diagnosis and error reporting, instead of CEEDUMP etc; > that's because we needed a special kind of reporting, which included > some very important site specific informations. I did this in 2005 ca., > and it worked not only with this LE exit and CIBs, but also with normal > SPIE/STAE and EPIEs and other sorts of error interfaces (SDWAs) > and interfaces from home grown tools. > To use the CEECIB, we used the mapping macro CEECIB. > We used for example these fields in CEECIB: > MVC ERRCOD(4),CIB_ABCD > MVC ERRCOD+4(4),CIB_ABRC > MVC ERRCIB,CIB_COND > MVC ERRCIBA,CIB_OLD_COND > L R3,CIB_MACHINE > ----------------------- 738 line(s) not displayed -------- > AVPUTH 'CIB_BACK ',CIB_BACK > AVPUTH 'CIB_FWRD ',CIB_FWRD > AVPUTH 'CIB_COND ',CIB_COND > AVPUTH 'CIB_OLD_C ',CIB_OLD_COND > AVPUTH 'CIB_ABCD ',CIB_ABCD > AVPUTH 'CIB_ABRC ',CIB_ABRC > AVPUTC 'CIB_ABNAME',CIB_ABNAME > AVPUTH 'CIB_SV1 ',CIB_SV1 > AVPUTH 'CIB_SV2 ',CIB_SV2 > AVPUTH 'CIB_MID ',CIB_MID > AVPUTH 'CIB_RTCC ',CIB_RTCC > at the position CIB_MACHINE, a structure with the same layout > as EPIE is recorded, so you get the PSW at the time of error > and the contents of the registers. > From the PSW and the registers, you are able to compute the entry point > of the current function and the name of the function and all the other > information > in the traceback ... that's what I did in my error diagnosing routine. > Register 13 > is the pointer to the current DSA (= stack frame). I'm doing classes > from time to > time on these topics (dump diagnosis etc.), where all this is covered. > Normally, you are not able to tell the source line of the error; only > the offsets > relative to the EPA of the function or to the load point of the module. > To tell the > source line, the load module must contain a table for the translation of > the offsets > into source line numbers (in PL/1: compile option GONUMBER). Our error > diagnosis > doesn't do that; it "only" tells the name of the procedure or function > and the two offsets; > but that is sufficient for the developers. > If you need more information, feel free to contact me offline. > Kind regards > Bernd > Am 22.01.2015 um 19:48 schrieb Charles Mills: > > Bernd - > > > > Thanks much! > > > > Really. :-) > > > > Yes, I did not mention it, but when I catch conditions (in a generic sense > > of the word) in a signal handler then CEE3DMP shows the real error location. > > You can return from a signal handler so the stack is preserved. It appears > > the stack is unwound on a catch() -- from which there is no return (to the > > point of failure). > > > > That is encouraging news on the CIB -- implies that a CIB may be created on > > a C++ exception that leads to a catch(). > > > > Is the CIB documented anywhere? All I have found are the leawi.h header and > > a couple of fields documented in the LE P/G. > > > > What fields do you find useful? Is there anything close to the line number > > and function or module name for the error? > > > > Charles > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Bernd Oppolzer > > Sent: Thursday, January 22, 2015 10:28 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: In C++ any way to get traceback info in a catch()? > > > > Am 22.01.2015 um 18:13 schrieb Charles Mills: > >> I am catching a bad_alloc exception in a catch() block. I call CEE3DMP > >> but the stack has been unwound > > Really? > > > > If I have a similar situation for example with PL/1, where an exception is > > caught by a PL/1 ON ERROR UNIT, I get a traceback which looks like that: > > > > CEEDUMP called by > > ON ERROR unit called by > > some LE error handling stuff called by > > the routine getting the exception (with the CIB) called by > > PL/1 main (for example) called by > > LE initialization stuff. > > > > that is, the stack at the time of the ON ERROR unit still contains the > > routine with the exception. So I have no problem seeing the routine that > > caused the error. > > I guess: signal handling in C will do the same. > > > > Is the try/catch logic in C++ that different? -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637 Cary, NC 27513 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
