In article <01a301d21fe6$1dbcd760$59368620$@mcn.org> you wrote:
> I have been wrestling with the issue of recovery from a failure of 'new'
> (kind of like a GETMAIN for those of you who are not C people; just like
> malloc() for those of you who are C but not C++ people) in XLC/LE C++ code.
> (Yes, I know, the right answer is "don't do too many 'new's" but this is
> error recovery code. Stuff happens, or IBM would not have invented ESTAE.
> "More region size" is not the answer -- this is an intentional test of
> storage exhaustion. More storage would just make it slower to fail <g>.)
> First I got past the non-standard behavior of XLC in that rather than
> blowing up per the standard, XLC just returns NULL (0) for a failed new. Got
> the LANGLVL(NEWEXCP) in place.
> So I am catching 'new' exceptions. The next problem was that it was
> impossible to do anything meaningful after catching the 'new' exception
> because storage was exhausted. So I read somewhere that one had to specify
> #pragma RUNOPTS( STORAGE(,,,32K) ) to reserve some storage for the storage
> exhaustion case. I specified 48K just to be on the safe side. This made
> things better: I go through my error recovery, clean things up, and end
> gracefully.
> The remaining problem is that I am not getting any diagnostic information,
> in other words, exactly *which* new failed -- which will of course make any
> bug of this sort in the field hard to find. I call CEEDUMP to get a call
> trace and it produces an *empty* four-line dataset. On the console I get
> IEW4000I FETCH FOR MODULE CEEMENU3 FROM DDNAME *VLF* FAILED BECAUSE
> INSUFFICIENT STORAGE WAS AVAILABLE.
> CSV031I LIBRARY ACCESS FAILED FOR MODULE CEEMENU3, RETURN CODE 24, REASON
> CODE 26080021, DDNAME *LNKLST*
> Any suggestions?
> Charles
Don't call CEEDUMP. Call abort() or something like:
{int *ptr; ptr = 0; *ptr = 1;}
Add another runopts:
#pragma runopts(TERMTHDACT(UADUMP))
and make sure you have a SYSMDUMP DD with a dataset to use later with
IPCS.
IP VERBX LEDATA 'ceedump nthreads(*)'
will give you tracebacks for all threads including the one that caused
the abend.
--
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
