Your example of 4K is important because it is a page in size. A page can only have one key and can only have one sub-pool associated with it at a time.
Common memory excepted, once the page is freed, it can be re-assigned into any key or sub-pool. Common memory has a whole different set of rules. Multiple GETMAIN requests for less than a page can be satisfied on one page as long as they are for the same key and sub-pool. Once all GETMAINed memory has been freed on that page, then the page can be re-used. Generally speaking, a page sized request will return a zeroed page, but there is no guarantee for that unless you specify that on the GETMAIN. Any GETMAIN for less than a page you need to zero the area yourself because there might be residual data from a previous GETMAIN/FREEMAIN request. In any case, it will never be data from another address space as that would violate security. Chris Blaicher Technical Architect Mainframe Development Syncsort Incorporated 2 Blue Hill Plaza #1563, Pearl River, NY 10965 P: 201-930-8234 | M: 512-627-3803 E: [email protected] www.syncsort.com CONNECTING BIG IRON TO BIG DATA -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Itschak Mugzach Sent: Saturday, January 7, 2017 11:40 AM To: [email protected] Subject: Re: Clarification On Storage Paul Getmain (in private area as you described) in not a real memory frame (which is the term for real memory 4k). It get the key based on the subpool you specify in the macro. So, in short, it is only visible through your asid page tables. Once your asid ends, so does the page tables. This is why we still use the term mvs. It is complely virtual. Common area is a bit different as they pre allocated, but this is not what you was asking. ITschak בתאריך 7 בינו 2017 17:10, "[email protected]" <[email protected]> כתב: > . > I recently read a share presentation on system integrity by Karl Schmitz. > Being a CICS Sysprog I dont get much opportunity to do some of the > topics Karl discussed. > . > . > I do have a question or should I say clarification about STORAGE. > I also looked at the z/OS Authorized Assembler Services guide. > . > Lets say a Non Authorized program runs in Key 8 and issues a > STORAGE/GETMAIN macro for 4096 Byes and the system returns an address > of 01B00C00 (an arbitrary address). > This Non Authorized Program process its data, FREMMAINs the 4096 Bytes > of storage and returns. > , > . > At some time latter An Authorized Program is started and requests 4096 > Bytes of storage in KEY 4. The system returns the same address > 01B00C00 that the Non Authorized Program used. > . > After reviewing Principles of Operation My understanding is that every > page of storage also has a storage kry, which consists of access > control bits, fetch protection bit, reference bit, and a change bit. > . > . > In My scenario I suspect the Operating System changed the storage > access control bits to key 4 to satisfy this request. Assuming the > same address was returned by GETMAIN/STORAGE. > Is My assessment correct ? > . > Im not aware of the operating system pre-allocating Pages of storage > by key ? > Do I understand this correctly ? > . > . > I apologize if this is a novice questions, but Inquiring minds want to > know. > . > . > . > Thanks In Advance > Paul > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ________________________________ ATTENTION: ----- The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
