On Mon, 16 Jun 2025 at 18:09, Charles Mills <[email protected]> wrote:
> [...] > 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.) > Thoughts: If you're truly out of private storage I'd expect an IEA message for a failing GETMAIN or STORAGE OBTAIN. Does anything other than browsing the SYSUDUMP support the theory of exhausted storage? That is, exhausted but not (yet) to the point of a GETMAIN failing... Changing the SYSUDUMP to SYSMDUMP (with a suitable dump-shaped allocation) would nmake things easier to read and search. And you'd be able to see at least some of the trace table. But really you want an earlier dump - LE and whatever IDI... is (debugger?) are all gonna be in there ahead to mess things up. So if possible you probably want a SLIP, but if you're not actually getting a GETMAIN failure then that'll be harder. You could do a SLIP on any abend - yeah, it'll probably catch something you don't care about, but then maybe it'll be the real problem. I don't seem to have enough disk space for an SVC dump. > That's easily fixed, but an earlier transaction dump taken by LE is probably beter than a later SVC dump. > > Anyone ever see anything like this? Anyone have any clues to what the > problem is? > No. Subpool 2 is not something I remember bumping into. I don't think it's LE or any core MVS service - it's a user subpool (private and no privs required) so I'd guess it's a "user" program running in your address space. Again, that IDI...? 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. > I forget where, but you can force the allocation for a transaction dump to go somewhere else. > 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 > > The above is probably useless. LE is notorious for clobbering the useful info before it "summarizes" what's left for you. > 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 > I keep harping on this because I don't know what IDI... is. But it's a likely culprit, in my view. > > 16.52.50 JOB04842 $HASP375 xxxxxxCR ESTIMATED LINES EXCEEDED > etc. for 4 million lines of SYSUDUMP > > Again, SYSMDUMP. Keep us posted. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
