Try REGION=6M or 20M. This should be small enough to get a dump. Probably looping somewhere by this time.
On Mon, Jun 16, 2025 at 11:56 PM Tony Harminc <[email protected]> wrote: > 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 > -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
