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:
----------------------- 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
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
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
If you need more information, feel free to contact me offline.
Am 22.01.2015 um 19:48 schrieb C.M.:
> Bernd -
> Thanks much!
> 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?
> -----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 C.M.:
>> I am catching a bad_alloc exception in a catch() block. I call CEE3DMP
>> but the stack has been unwound
> 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?
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to email@example.com with the message: INFO IBM-MAIN