Hi Charles,
Subpool 2, IIRC, is the normal subpool LE uses for additional space
required for heap allocations in MVS (a.k.a z/OS).
Subpool 1 is different; I don't recall the difference; maybe 1 is for
stack and 2 for heap or 1 is for primary allocations
and 2 for secondary.
This said:
I occasionally resolved such issues by switching to the alternate LE
storage manager, which shows a traceback
of the callers on every alloc and free request. Something like CEL4MCHK.
I have not much time now, but I have
a presentation on that somewhere. Maybe you find it using Google. It is
not that easy, because to get a clear picture,
you have to examine the large trace output produced by CEL4MCHK and find
a pattern (which routine acquires
storage and fails to free it). But doing this, I always found the C++
routines producing the memory leaks.
This is the same method which on other platforms is done using a tool
called ValGrind, IIRC.
HTH, kind regards
Bernd
Am 17.06.2025 um 00:09 schrieb Charles Mills:
I have a C++ program under development that has started ABENDing *after the
last line* of the program. The main() routine ends with
printf("Last line of main()\n");
return M::ProgramReturnCode;
and I am seeing that printf() message, so the problem is not something that the
program is doing explicitly in my logic.
Storage is apparently being exhausted, despite REGION=0M. In the SYSUDUMP I see
allocation after allocation -- 13,000 lines or so -- of x'21000' bytes in
subpool 2. What IBM component uses subpool 2? (My code does not use subpool 2
explicitly.)
I don't seem to have enough disk space for an SVC dump.
Anyone ever see anything like this? Anyone have any clues to what the problem
is?
Here are the messages I am seeing
16.52.47 JOB04842 +CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4088 TO DATA
SET: xxxxxx.D167.T1652476.xxxxxxCR
16.52.49 JOB04842 IKJ56245I DATA SET xxxxxx.D167.T1652476.xxxxxxCR NOT
ALLOCATED, NOT ENOUGH SPACE ON VOLUMES+
16.52.49 JOB04842 IKJ56245I USE DELETE COMMAND TO DELETE UNUSED DATA SETS
16.52.50 JOB04842 IEA820I TRANSACTION DUMP REQUESTED BUT NOT TAKEN 814
814 AUTOMATIC ALLOCATION OF DUMP DATA SET FAILED
16.52.50 JOB04842 +CEE3796I AN ATTEMPT TO DYNAMICALLY TAKE A DUMP WAS NOT
SUCCESSFUL. 815
815 THE ERROR RETURN CODE WAS 00000008 AND THE REASON CODE WAS
00000026.
16.52.50 JOB04842 +CEE0374C CONDITION=CEE3204S TOKEN=00030C84 59C3C5C5
00000000 816
816 WHILE RUNNING PROGRAM CERTREPT
816 AT THE TIME OF INTERRUPT
816 PSW 078D0400 9A804D70
816 GPR 0-3 00000000 00000000 00000000 00000008
816 GPR 4-7 00791860 1B41BB28 1A804D70 9A81EAA6
816 GPR 8-B 9A81EA6C 1B424800 1B417D70 86087018
816 GPR C-F 1A9181D8 1B17C840 00000002 00000002
16.52.50 JOB04842 +IDI0012S Abend 0000C9 occurred in abend exit processing,
16.52.50 JOB04842 +IDI0013S R15=0 PSW=078D0000 1A72B7D6 DCAPSUB=1A713A80
16.52.50 JOB04842 IEA043I SVC DUMP REACHED MAXSPACE LIMIT - MAXSPACE=00000500
MEG
16.52.50 JOB04842 IEA794I SVC DUMP HAS CAPTURED: 821
821 DUMPID=001 REQUESTED BY JOB (xxxxxxCR)
821 DUMP TITLE=IDIDA ESTAE exit entered. JOB04842
SDWA
821 =7F510B58
821 INSUFFICIENT RESOURCES FOR OPTIMIZE=YES PROCESSING
16.52.50 JOB04842 $HASP375 xxxxxxCR ESTIMATED LINES EXCEEDED
etc. for 4 million lines of SYSUDUMP
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
