The content of the getmained area is much depend on language command and options (COBOL initialize foe example).
ITschak נשלח מה-iPad שלי ב-7 בינו׳ 2017, בשעה 21:57, Clark Morris <[email protected]> כתב/ה: > [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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
