On 01/07/2017 09:07 AM, [email protected] wrote: > . > 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 > Storage requests implicitly or explicitly are from a specific storage pool based on key requirements and how long the data needs to persist, and some pools are restricted based on authorization of the requester. The rules for allowed storage key values are pool specific. Released storage may stay for a while as free storage in that same pool -- don't remember the exact rules here -- but the association with storage pools would reduce the likelihood that a subsequent program in that same address space would later get storage at the same virtual address as was used fora different storage key. Also keep in mind we are talking here about virtual storage, not real storage frames. My understanding is that when whole pages of virtual storage are released back to a pool the association with real page frames and related data is tossed; and when whole pages are allocated from a storage pool no real storage frames are actually associated with the pages until first reference to each new page, at which point it is associated with a zeroed real page. So even if unused virtual storage were released from one storage pool and reassigned to another and a range of virtual address space switched pools, the new storage pool wouldn't see any data related to the previous storage pool. And of course with MVS-z/OS the virtual storage of different address spaces or regions are isolated from each other(except for the shared "common" area which is controlled by authorized programs). Joel C. Ewing
-- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
