In z/OS 2.2 and above, each address space has a new control block in 64-bit common storage which can be used to monitor these boundaries - IHALDAX, pointed to by ASSBLDAX.
LDAX_LDACRGTP DS A Current high address of PRIVATE AREA Region LDAX_LDAERGTP DS A Current high address of EXTENDED PRIVATE AREA Region LDAX_CurHighBot DS A < 16M Cur bot Auth area LDAX_CurEHighBot DS A > 16M Cur bot EAuth area Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 06/08/2018 08:04:30 AM: > From: "Vernooij, Kees (ITOPT1) - KLM" <kees.verno...@klm.com> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 06/08/2018 11:50 AM > Subject: Re: Userarea and Systemarea crossing. > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > After some Googling, I found the answer in an MQ Q&A site: > > "For the LSQA getmain failure, it is possible that the Extended User > Region Top for the CHIN job has hit the bottom of Extended LSQA > because Virtual Storage Manager (VSM) private storage use is high, > for example Subpool 0 Key 8 (SP0 KEY8) and Subpool 131 Key 8 (SP131 KEY8)." > > So the answer is: yes, it applies to private and extended private. > > Kees. > > From: Vernooij, Kees (ITOPT1) - KLM > Sent: 08 June, 2018 11:24 > To: 'IBM-MAIN@listserv.ua.edu' <IBM-MAIN@listserv.ua.edu> > Subject: Userarea and Systemarea crossing. > > Hello, > > When getmaining storage in my address space the user- and system- > area cannot cross: the highest user area block (getmained from the > bottom) cannot pass the lowest system area block (getmained from the > top) and vica versa. > Is this a rule for both below and above 16 MB? I know it is for > <16MB, but I cannot find if this is also true for >16MB. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN