On Fri, 23 Jan 2015 09:01:52 -0800, Charles Mills wrote:
FWIW, no, I never wrote the words register 13. I want a traceback.
For all I care it could be based on R13 or breadcrumbs or footprints in
the sand.
Sorry, I thought I remembered R13 somewhere in this thread. Maybe it
was someone else.
Great minds think alike.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Carl Kugler
Sent: Friday, January 23, 2015 9:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: In C++ any way to get traceback info in a catch()?
How
Right. And XPLINK implies PDSE. Nothing is simple. I think I only have one
assembler routine that is used after initialization, so I could re-write that
and live with a performance hit on all of the others.
FWIW, no, I never wrote the words register 13. I want a traceback. For all I
care it
How about using set_new_handler() in your main() to register a new_handler()
that does a ctrace() followed by a throw(std::bad_alloc)?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
Thanks. No question, that concerns me.
I don't do any explicit new's in any of the processing I detail below. Does the
C++ library do a new or malloc() under the covers? Who knows. Do I use stack?
Of course. I suppose one advantage of throwing an exception would be that it
would free up stack.
Works like a champ! That is exactly what David Crayford (thank you, David!)
suggested off-line. I followed the spirit of this, but did things somewhat
differently. In my new handler, I
- Put out a diagnostic message
- Call CEE3DMP
- Call my existing clean-up-and-terminate routine.
The dump is
On Fri, 23 Jan 2015 10:50:50 -0800, Charles Mills charl...@mcn.org wrote:
Works like a champ! That is exactly what David Crayford (thank you, David!)
suggested off-line. I followed the spirit of this, but did things somewhat
differently. In my new handler, I
- Put out a diagnostic message
-
On Fri, 23 Jan 2015 11:26:06 -0800, Charles Mills charl...@mcn.org wrote:
In my test it is one 6.3MB new that fails. So I presumably have lots of spare
heap; just not 6.3MB. If the failure were due to a loop that did lots of tiny
new's then that would not be the case. If the loop involved
Am 23.01.2015 um 02:53 schrieb Sam Siegel:
On Jan 22, 2015 4:53 PM, Charles Mills charl...@mcn.org wrote:
Ah, thanks. I keep forgetting that. Oddly named manual, IMHO.
Anyway, I don't think I have a CIB. I think this condition is totally
internal to C++ -- not an LE condition.
Please take at
Now that I think about it though, we used to pay for ASKQ. I'm not
sure if it's still called that. Check if you have that addon to
IBMLINK.
In article 20150123044405.9b45b2e...@panix3.panix.com you wrote:
Sure, you can ask how. There's no guarantee you'll like the answer. :)
In article
On Thu, 22 Jan 2015 20:11:12 -0800, Charles Mills wrote:
Mmm. I'm going to make the 64-bit leap one of these days. I should set the
option and compile everything and see what errors I get. That would be a
first clue as to how big a leap.
Be aware that C/C++ running AMODE 64 is XPLINK. Program
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()
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*.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
On Jan 22, 2015 4:53 PM, Charles Mills charl...@mcn.org wrote:
Ah, thanks. I keep forgetting that. Oddly named manual, IMHO.
Anyway, I don't think I have a CIB. I think this condition is totally
internal to C++ -- not an LE condition.
Please take at least a quick look at the le manuals. As
Charles,
Same header. struct __mch. But you're right, if the LE ESTAE isn't invoked,
none of this is going to get set. Open an ETR and ask IBM how to do what
you want.
__le_api.h
In article 04ba01d0369a$cc5f3740$651da5c0$@mcn.org you wrote:
Don, thanks. To clarify, there is no ABEND type
Can I ask IBM *how*? Don't I have to say catch() traceback is broken and
let them argue with me?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Don Poitras
Sent: Thursday, January 22, 2015 7:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Charles,
Sorry about that. Almost all the work I do in IBM C is in 64-bit.
In article 04b301d03699$53ae6a60$fb0b3f20$@mcn.org you wrote:
Grumble, grumble. __le_traceback() is AMODE 64 only. (Noticed that after
spending about an hour trying to get the example to compile.)
Charles
Mmm. I'm going to make the 64-bit leap one of these days. I should set the
option and compile everything and see what errors I get. That would be a
first clue as to how big a leap.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
Sure, you can ask how. There's no guarantee you'll like the answer. :)
In article 050801d036c3$c42cd720$4c868560$@mcn.org you wrote:
Can I ask IBM *how*? Don't I have to say catch() traceback is broken and
let them argue with me?
Charles
-Original Message-
From: IBM Mainframe
Grumble, grumble. __le_traceback() is AMODE 64 only. (Noticed that after
spending about an hour trying to get the example to compile.)
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Don Poitras
Sent: Thursday, January 22,
I am beginning to suspect I do not have a meaningful CIB. My CEE3DMP
includes the (default) option CONDITION but there do not appear to be any
CIBs in the dump.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Bernd Oppolzer
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
Ah, thanks. I keep forgetting that. Oddly named manual, IMHO.
Anyway, I don't think I have a CIB. I think this condition is totally internal
to C++ -- not an LE condition.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Sam
In
cafmxnwkytsctkf3gpxufyx6qtek9tnj7m1mnjos0ilv-k4o...@mail.gmail.com,
on 01/22/2015
at 03:51 PM, Sam Siegel s...@pscsi.net said:
Look in LE vendor interface manual for all of the LE control blocks.
All? DCLCB? FCB?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see
The CIB is described in __le_api.h. There's a useful function for producing
tracebacks, __le_traceback. The doc has sample code calling it in C.
https://www-304.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxbd00/letraceback.htm?lang=en
In article
ceecib is documented in LE vendor interface manual
On Thu, Jan 22, 2015 at 10:48 AM, Charles Mills charl...@mcn.org wrote:
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
Thanks! Do you have any idea whether __le_traceback will produce meaningful
results in a situation in which CEE3DMP does not output a useful traceback?
The C++ stack has apparently already been unwound when C++ enters a catch()
block. The catch() block appears to have been called from the point at
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
Am 22.01.2015 um 20:22 schrieb Charles Mills:
Thanks! Do you have any idea whether __le_traceback will produce meaningful
results in a situation in which CEE3DMP does not output a useful traceback?
The C++ stack has apparently already been unwound when C++ enters a catch()
block. The catch()
I just looked at the description of __le_traceback().
It looks as if it can be called with the DSA from the CIB;
this way, it should give you all the information you need, IMO.
In the calling example we have:
tbck_parms.__tf_dsa_addr = 0;
|
this should be changed for our situation, I think.
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
31 matches
Mail list logo
