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 <[email protected]> wrote on
06/08/2018 08:04:30 AM:
> From: "Vernooij, Kees (ITOPT1) - KLM" <[email protected]>
> To: [email protected]
> Date: 06/08/2018 11:50 AM
> Subject: Re: Userarea and Systemarea crossing.
> Sent by: IBM Mainframe Discussion List <[email protected]>
>
> 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: '[email protected]' <[email protected]>
> 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 [email protected] with the message: INFO IBM-MAIN
