Re: Userarea and Systemarea crossing.
Also note that SDSF for z/OS 2.3 added the following columns on the "AS" command display populated by the data in the LDAX : Priv PrivUsed Priv% EPriv EPrivUsed EPriv% Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Friday, June 8, 2018 4:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Userarea and Systemarea crossing. 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_LDACRGTPDSA Current high address of PRIVATE AREA Region LDAX_LDAERGTPDSA Current high address of EXTENDED PRIVATE AREA Region LDAX_CurHighBot DSA < 16M Cur bot Auth area LDAX_CurEHighBot DSA > 16M Cur bot EAuth area Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY IBM Mainframe Discussion List wrote on 06/08/2018 08:04:30 AM: > From: "Vernooij, Kees (ITOPT1) - KLM" > 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 > > After some Googling, I found the answer in an MQ Q 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' > 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 Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Userarea and Systemarea crossing.
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_LDACRGTPDSA Current high address of PRIVATE AREA Region LDAX_LDAERGTPDSA Current high address of EXTENDED PRIVATE AREA Region LDAX_CurHighBot DSA < 16M Cur bot Auth area LDAX_CurEHighBot DSA > 16M Cur bot EAuth area Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY IBM Mainframe Discussion List wrote on 06/08/2018 08:04:30 AM: > From: "Vernooij, Kees (ITOPT1) - KLM" > 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 > > After some Googling, I found the answer in an MQ Q 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' > 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
Re: Userarea and Systemarea crossing.
After some Googling, I found the answer in an MQ Q 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' 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. Thanks, Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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. Thanks, Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
