While z/OS may be the only supported MVS, everything from OS/VS2 R2.0 through OS/390 is also MVS, and there is even a turnkey system available for OS/VS2 R3.8 that runs under Hercules. i don't know whether anybody has an old box still running OS/390.
My recollection is that the TMP and TSO service routines use SP1. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Bernd Oppolzer <[email protected]> Sent: Tuesday, June 17, 2025 1:13 AM To: [email protected] <[email protected]> Subject: Re: Looking for clues on out-of-storage at end-of-jobstep External Message: Use Caution 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
