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 <[email protected]> On Behalf Of Jon
Perryman
Sent: Tuesday, January 30, 2024 3:06 PM
To: [email protected]
Subject: Re: Regarding RBINTCOD
On Tue, 30 Jan 2024 20:05:50 +0200, Binyamin Dissen
<[email protected]> 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 [email protected] with the message: INFO IBM-MAIN
