[Default] On 7 Jan 2017 08:56:33 -0800, in bit.listserv.ibm-main [email protected] (Blaicher, Christopher Y.) wrote:
>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. If the "physical" page is not zeroed, what would be there other than data left from a previous use. Actually the same concept would apply to all reused storage. Clark Morris > >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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
