Sounds to me like 48K is not enough to allow the CEEDUMP process to complete. 48K seems unreasonably low to me, I would make it 128K or even more to permit the CEEDUMP process to run. I would research the CEEDUMP documentation to see if the minimum storage requirements for it to succeed are published and if not open a PMR with IBM to ask for it.
Also, is that "storage exhaustion reserve" above the line or below the line? It might make a difference where it is reserved. HTH Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, October 06, 2016 11:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CEEDUMP possible following 'new' failure 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 -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
