Mmm. I hear you. May be the right answer. I am kind of in love with the "character" CEE3DMP because it is easy for customers to send and not screw up. Easy to view without uploading to the mainframe and firing up IPCS. Seems to point quickly to about 99 out of 100 problems.
I do call some terminate-type function. CEE3DMP() is not "fatal" -- it returns to the caller. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Don Poitras Sent: Thursday, October 06, 2016 8:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CEEDUMP possible following 'new' failure 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
