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

Reply via email to