As we have already discussed, program objects do get
rounded up to 4k multiples. Load modules do not.
I am a big fan of looking at dumps. We always have hundreds
of them readily available around here.
Here is an excerpt from SUMMARY FORMAT ASID(1) EX(GL)
on a z/OS 2.5 standalone dump.
There are multiple load modules on pages 0CB01000 and 0CB0D000.
EP....... IEFJMSGT
ENTPT.... 00000000 8CB0E228 RRBP..... 00000000 USE...... 0001
SP....... FC
Reenterable. Reusable.
APF library.
NRFAC.... 00000001 MSBAD.... 00000000 0CB0D8A0 LNTH..... 00000B20
NAMEL.... 0008 ASID..... 0001 PROVIDI.. 00000002 PROVIDD..
00010000 02330E0D 60D3D5D2 D3E2E360
EPTOKEN.. 000001B3 0001004D
EP....... ISNGENEX
ENTPT.... 00000000 8CB01C10 RRBP..... 00000000 USE...... 0001
SP....... FC
Reenterable. Reusable.
APF library.
NRFAC.... 00000001 MSBAD.... 00000000 0CB01C10 LNTH..... 000003A8
NAMEL.... 0008 ASID..... 0001 PROVIDI.. 00000002 PROVIDD..
00010000 011C070D 60D3D5D2 D3E2E360
EPTOKEN.. 000001B0 0001000E
EP....... ISNAXOSV
ENTPT.... 00000000 8CB06868 RRBP..... 00000000 USE...... 0001
SP....... FC
Reenterable. Reusable.
APF library.
NRFAC.... 00000001 MSBAD.... 00000000 0CB06868 LNTH..... 00000650
NAMEL.... 0008 ASID..... 0001 PROVIDI.. 00000002 PROVIDD..
00010000 011E0D0D 60D3D5D2 D3E2E360
EPTOKEN.. 000001AF 0001002C
EP....... ISNAXOCF
ENTPT.... 00000000 8CB0D000 RRBP..... 00000000 USE...... 0001
SP....... FC
Reenterable. Reusable.
APF library.
NRFAC.... 00000001 MSBAD.... 00000000 0CB0D000 LNTH..... 000008A0
NAMEL.... 0008 ASID..... 0001 PROVIDI.. 00000002 PROVIDD..
00010000 011E040D 60D3D5D2 D3E2E360
EPTOKEN.. 000001AE 0001000D
EP....... ISNET4
ENTPT.... 00000000 8CB05AC8 RRBP..... 00000000 USE...... 0001
SP....... FC
Reenterable. Reusable.
APF library.
NRFAC.... 00000001 MSBAD.... 00000000 0CB05AC8 LNTH..... 000007F8
NAMEL.... 0008 ASID..... 0001 PROVIDI.. 00000002 PROVIDD..
00010000 0127180D 60D3D5D2 D3E2E360
EPTOKEN.. 000001A8 00010031
EP....... ISNMDB
ENTPT.... 00000000 8CB01558 RRBP..... 00000000 USE...... 0001
SP....... FC
Reenterable. Reusable.
APF library.
NRFAC.... 00000001 MSBAD.... 00000000 0CB01558 LNTH..... 000006B8
NAMEL.... 0008 ASID..... 0001 PROVIDI.. 00000002 PROVIDD..
00010000 011B040D 60D3D5D2 D3E2E360
EPTOKEN.. 000001A7 00010011
EP....... ISNSTATE
ENTPT.... 00000000 8CB011D8 RRBP..... 00000000 USE...... 0001
SP....... FC
Reenterable. Reusable.
APF library.
NRFAC.... 00000001 MSBAD.... 00000000 0CB011D8 LNTH..... 00000380
NAMEL.... 0008 ASID..... 0001 PROVIDI.. 00000002 PROVIDD..
00010000 011E270D 60D3D5D2 D3E2E360
EPTOKEN.. 000001A6 00010065
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
"IBM Mainframe Discussion List" <[email protected]> wrote on
08/31/2021 11:23:11 PM:
> From: "CM Poncelet" <[email protected]>
> To: [email protected]
> Date: 09/01/2021 01:30 AM
> Subject: Re: RENT binder option
> Sent by: "IBM Mainframe Discussion List" <[email protected]>
>
> "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.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
