If the issuer of ESTAE(X) was system key (0-7), the SDWA is obtained from subpool 230 (high private, not subject to the region limit). For user key, the SDWA is obtained from subpool 0 (low private, subject to the region limit), so R0=12 is more likely for this case, Especially if the abend being handled is due to region exhaustion.
There is no 1M between 2047M and 2048M, since both of those values are considerably higher than what could ever be available, after you subtract the 16M that is below 16M, and whatever is the size of ENUC+ELPA+ECSA+ESQA. No limits are bypassed, and currently, nothing is reserved. I have been recently working on implementing on an idea I had 20 years ago to maintain a minimum area between the current top of low private and the current bottom of high private, so that low private cannot go into this area, and if high private intrudes more than halfway into this area, VSM initiates a cancel of the job. That would help to reduce 40D-10 abnormal memterms when RTM2 can't get storage below 16M for the IHARMPL, and reduce situations where we can't obtain an SDWA for a system key ESTAE(X). It would also help with the situation that Seymour Metz mentions now and then, that anyone can easily memterm an initiator by running a simple program that SYNCHes to itself infinitely (since that will exhaust private storage below 16M with PRBs). For example, this is what happens currently: CMN JOB00022 IEF403I SYNCHSLF - STARTED - TIME=03.15.45 CMN IEA045I AN SVC DUMP HAS STARTED AT TIME=03.15.49 DATE=01/31/2024 FOR ASID (0028) ERROR ID = SEQ00019 CPU00 ASID0028 TIME03.15.49.8 QUIESCE = YES CMN JOB00022 IEA794I SVC DUMP HAS CAPTURED: DUMPID=002 REQUESTED BY JOB (SYNCHSLF) DUMP TITLE=COMPID=SC1CJ,COMPON=CONTENTS SUPERVISOR,ISSUER=CSVFR R,878-0000000C IN IGVVSERR+0F82. INSUFFICIENT RESOURCES FOR OPTIMIZE=YES PROCESSING CMN IEA045I AN SVC DUMP HAS STARTED AT TIME=03.15.50 DATE=01/31/2024 FOR ASID (0028) ERROR ID = SEQ00019 CPU00 ASID0028 TIME03.15.49.8 QUIESCE = NO *CMN *IEA911E COMPLETE DUMP ON SYS1.DUMP30 *DUMPID=002 REQUESTED BY JOB (SYNCHSLF) *FOR ASID (0028) *INCIDENT TOKEN: UTCPLXHD CMN 01/31/2024 03:15:49 * ERROR ID = SEQ00019 CPU00 ASID0028 TIME03.15.49.8 *ID = SC1CJ:878-0000000C IN IGVVSERR+0F82. CMN JOB00022 IEA794I SVC DUMP HAS CAPTURED: DUMPID=003 REQUESTED BY JOB (SYNCHSLF) DUMP TITLE=ABEND=40D,RC=10,COMPON=RTM2,COMPID=SCRTM,ISSUER=IEAV TRT2,MEMTERM - UNRECOVERABLE ABEND FAILURE INSUFFICIENT RESOURCES FOR OPTIMIZE=YES PROCESSING CMN IEF402I INIT FAILED IN ADDRESS SPACE 0028 SYSTEM ABEND S40D - REASON CODE 10 CMN IEF402I SYNCHSLF FAILED IN ADDRESS SPACE 0028 SYSTEM ABEND S40D - REASON CODE 10 *CMN *IEA911E COMPLETE DUMP ON SYS1.DUMP31 *DUMPID=003 REQUESTED BY JOB (SYNCHSLF) *FOR ASID (0028) *INCIDENT TOKEN: UTCPLXHD CMN 01/31/2024 03:15:50 CMN JOB00022 $HASP310 SYNCHSLF TERMINATED AT END OF MEMORY CMN STC00004 $HASP310 INIT TERMINATED AT END OF MEMORY CMN STC00023 IEF403I INIT - STARTED - TIME=03.15.56 But with a minimum area of 50K below 16M, and 1M above 16M, CMN JOB00024 IEF403I SYNCHSLF - STARTED - TIME=03.19.21 CMN JOB00024 IEF450I SYNCHSLF SYNCHSLF - ABEND=S822 U0000 REASON=00000004 TIME=03.19.26 CMN JOB00024 IEF404I SYNCHSLF - ENDED - TIME=03.19.26 . So maybe that will get into the next release after z/OS 3.1. Jim Mulder -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Jon Perryman Sent: Tuesday, January 30, 2024 3:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Regarding RBINTCOD On Tue, 30 Jan 2024 20:05:50 +0200, Binyamin Dissen <bdis...@dissensoftware.com> wrote: >:>Jon P did write what I meant. Answer: no, it just makes it a lot more likely >that the storage obtain for the SDWA will succeed. > >Sad. I believe abend recovery R0=12 is virtually unheard of when SDWA is above the line. Realize that REGION=2048M is not valid and 2047M is the max. I suspect that IBM reserves this last 1M for situations like this. Additionally, running out of 2GB of storage is very rarely from <1K storage obtains. SDWA is small and enough storage should be available. Far more concerning would be S878 abend recovery. Does abend recovery automatically bypass storage limits during S878 abend recovery? If not, is there a mechanism to bypass it temporarily? I've used STORAGE OBTAIN,COND=YES and when it fails, percolate it to IBM recovery. For common recovery in product environments, this is not the best solution but it works most of the time. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN