No. That is not and has never been true; small load modules are not page aligned. The devil is in the details.
BTW, MOD is an SMP term; what fetch deals with in load modules is csects and enty points. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of CM Poncelet [[email protected]] Sent: Tuesday, August 31, 2021 11:23 PM To: [email protected] Subject: Re: RENT binder option "Not all modules have or need a 4 KiB alignment." Indeed, for "modules" (as in CSECT/RSECT MODs, within an LMOD.) But LMODs themselves are loaded into page-aligned storage. The LP (load point) addresses of LMODs always end with x'000' (i.e. page-aligned) - and the addresses of all MODs they contain always ends with x'0' or x'8', as in DWORD-aligned, *but* if these MODs are SYSLIN "ORDER" link-edited as (P) [page-aligned] or SYSLIN "PAGE" link-edited [likewise page-aligned,] then their addresses always end with x'000'. This can be seen, checked and verified in/from system dumps. GETMAINs (aka STORAGE OBTAINs) are allocated in contiguous DWORD-aligned storage within a same (or following) page, as too (usually) are MODs within an LMOD (unless the MODs are page-aligned, as mentioned above.) FREEMAINs (aka STORAGE RELEASEs) supposedly release GETMAINed storage. But they do not release a page until *all* GETMAINed storage within it has been FREEMAINed. Hence, e.g. MVCLs will continue to complete successfully from one DSECT to another DSECT mapped over released GETMAINed storage - not because this storage is still GETMAINed, but because the page still contains some un-FREEMAINed storage and the page therefore remains allocated and addressable (regardless of [some of] its storage having been FREEMAINed) until *all* GETMAINed storage in it has been FREEMAINed. On 31/08/2021 22:21, Seymour J Metz wrote: > 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 > . > ---------------------------------------------------------------------- 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
