What is absurd about a page containing more than on load module? It happens all the time. Not all modules have or need a 4 KiB alignment.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of CM Poncelet [[email protected]] Sent: Monday, August 30, 2021 11:29 PM To: [email protected] Subject: Re: RENT binder option FWIW and FYI. A 31-bit instrucion is a 4-byte fullword address, as e.g. say at virtual (DAT) address x'71234568'. The first 3 nybles (x'712') indicate the segment from which the LMOD's storage/address has been allocated. The next 2 nybles (x'34') are the offset to the page within the segment that is allocated to the LMOD's address. The last 3 nybles (x'568') are the offset within the allocated page of the LMOD's instruction address, within the segment. So a page, in nybles, is 16 x 16 x 16 = 4096 bytes or 4K - which is then used to build the LMOD's virtual (DAT) address. Hence, the OS allocates whole - not partial - 4K pages to a load module (LMOD). If the size of a REFR LMOD is < 8K but > 4K then the OS allocates two 4K pages to it (both of which are then REFR protected). If a page were partially occupied by a REFR LMOD but otherwise also occupied by another LMOD, this would lead to situations where, say, a 31-bit instruction at address x'71234568' could be part of a REFR LMOD but at address x'71234800' could be part of some other LMOD - and would imply that a same page had been allocated to more than one LMOD, which from an addressability point of view would be absurd. In other words, pages are either fully allocated/occupied to or by a REFR LMOD's code or they are not occupied by a REFR LMOD's code at all. HTH Cheers. On 30/08/2021 17:00, Paul Gilmartin wrote: > On Mon, 30 Aug 2021 09:49:14 -0400, Jim Mulder wrote: > >> The behavior of loading RENT modules from authorized >> libraries into subpool 252 (key 0) is to prevent them from >> being modified by unauthorized programs. That is intended >> to contribute to security. >> > It would be a courtesy, think of it as a lagniappe, to the customer > wanting to verify code implementation, to protect pages even partially > occupied by REFR code. > > -- gil > > ---------------------------------------------------------------------- > 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
