On Jan 22, 2015 3:26 PM, "Charles Mills" <charl...@mcn.org> wrote: > > Don, thanks. To clarify, there is no ABEND type condition. The exception in > questions is "out of storage" -- bad_alloc. > > Where is "machine block" documented or defined? cib_machine is a void*. >
Look in LE vendor interface manual for all of the LE control blocks. > Charles > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Don Poitras > Sent: Thursday, January 22, 2015 12:45 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: In C++ any way to get traceback info in a catch()? > > 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 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN