RENT binder option

[Frank Swarbrick]

For our COBOL program binder step we've never specified the RENT (or REUS=RENT) option, even though we always use the RENT compiler option. This has never seemed to cause us any problems. I now see in the Enterprise COBOL manual, section "Compiling programs to create DLLs"(https://www.ibm.com/docs/en/cobol-zos/6.3?topic=application-compiling-programs-create-dlls), where it states "Applications that use DLL support must be reentrant. Therefore, you must compile them with the RENT compiler option and link them with the RENT binder option." However, I've been doing testing with DLLs recently and have never had any (noticeable?) issues even though we are not specifying RENT or REUS=RENT.

So what's up with this? And what about for non-DLL dynamic calls? I've had no issues there, either.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN

[Attila Fogarasi]

The Binder RENT option is not needed for your use case, as you've
discovered, as it is for cases when the binder input isn't marked as RENT
already. Your Cobol compiles with the RENT option will pass that to the
Binder. The use case where RENT or REUS is needed is when there are
non-Cobol subroutines involved and you need to control the attributes for
correct execution. Cobol manual is a suggesting it is good practice to
specify the option as things could break with non-Cobol components added,
I'm pretty sure it is never needed for all Cobol.

On Sat, Aug 14, 2021 at 9:16 AM Frank Swarbrick <frank.s...@outlook.com>
wrote:

[Peter Relson]

At a minimum, what's "up" is that the system doesn't think your module is
reentrant because of your not using the binder option.
Therefore every time the system is asked to load the module, even if there
is already a usable copy in storage, another copy is fetched. That wastes
storage and CPU time and I/O time. If you don't care about that, so be it.
Most do.

And it is possible that there could be procedural dependencies on there
being a single copy..

Peter Relson
z/OS Core Technology Design

[Paul Gilmartin]

On Sat, 14 Aug 2021 08:39:02 -0400, Peter Relson wrote:
>
> ... [for NORRENT} every time the system is asked to load the module, even if there
>is already a usable copy in storage, another copy is fetched. ...

>
>And it is possible that there could be procedural dependencies on there
>being a single copy..
>

If the programmer issues DELETE, which copy is deleted?

-- gil

[Bernd Oppolzer]

IIRC, DELETE does not really DELETE the module, if the use count (which
is in some of
the control blocks) is not zero. The use count is incremented on every
LOAD, which refers
to the load module and decremented on every DELETE.

If there are more copies of the same module (in the NORENT case), there
must be
multiple control blocks, too (IMO), so that every copy has its own use count
(which is always 1, I guess).

Maybe I am mixing up the use count with another count, called
responsibility count;
there are two of them, IIRC.

One of them records the LOAD / DELETE sequences, and the other, AFAIK,
records the LINK / XCTL / ATTACH uses. It is important to know that normal
CALL does not change this count, because the op sys does not know about
CALLs to modules (using machine instructions).

It would be nice if someone who knows better could correct me on the
details.

Thanks, have a nice Sunday

Bernd

[Paul Gilmartin]

On Sat, 14 Aug 2021 20:02:42 +0200, Bernd Oppolzer wrote:

>IIRC, DELETE does not really DELETE the module, if the use count (which
>is in some of
>the control blocks) is not zero. The use count is incremented on every
>LOAD, which refers
>to the load module and decremented on every DELETE.
>

Does the storage for all those control blocks and the load modules remain
in use, reclaimed exactly when that use count reaches zero?

>If there are more copies of the same module (in the NORENT case), there
>must be
>multiple control blocks, too (IMO), so that every copy has its own use count
>(which is always 1, I guess).
>
>Maybe I am mixing up the use count with another count, called
>responsibility count;
>there are two of them, IIRC.
>
>One of them records the LOAD / DELETE sequences, and the other, AFAIK,
>records the LINK / XCTL / ATTACH uses. It is important to know that normal
>CALL does not change this count, because the op sys does not know about
>CALLs to modules (using machine instructions).
>
>It would be nice if someone who knows better could correct me on the
>details.
>

And document (RCF) the answer if appropriate.

>> On Sat, 14 Aug 2021 08:39:02 -0400, Peter Relson wrote:
>>> ... [for NORRENT} every time the system is asked to load the module, even if there
>>> is already a usable copy in storage, another copy is fetched. ...
>>>
>>> And it is possible that there could be procedural dependencies on there
>>> being a single copy..
>>>
>> If the programmer issues DELETE, which copy is deleted?

Thanks,

[Bernd Oppolzer]

Am 14.08.2021 um 20:46 schrieb Paul Gilmartin:
> On Sat, 14 Aug 2021 20:02:42 +0200, Bernd Oppolzer wrote:
>
>> IIRC, DELETE does not really DELETE the module, if the use count (which
>> is in some of
>> the control blocks) is not zero. The use count is incremented on every
>> LOAD, which refers
>> to the load module and decremented on every DELETE.
>>
> Does the storage for all those control blocks and the load modules remain
> in use, reclaimed exactly when that use count reaches zero?

Yes , the modules (and the control blocks - CDE, XTLST, LLE) remain in
storage,
as long as the use count does not reach zero.

We once had the situation at a site of a customer of mine, that a module
was called
many times using the following sequence of macro calls:

- LOAD (to keep the module in place between subsequent calls)
- CEEFETCH (needed because of the PL/1 writable static area ... the
module called was PL/1
compiled with RENT option; the calling module was ASSEMBLER)
- then CALL using machine instructions
- (no DELETE, see comment above on LOAD)

this was a (sort of) error. The CEEFETCH did not load the module,
because it recognized
that there was a usable copy; the LOAD (2nd time and so on) also didn't
LOAD it again,
but every LOAD incremented the use count by one; it was never decremented.

The modules are all RENT in this installation.

This worked OK for some time, but ...

because the use count in the control block is limited to 16 bits (IIRC),
after 32k or 64k calls, a very strange ABEND occurred.

We fixed this by changing the calling sequence, eliminating the
CEEFETCH, BTW,
and changing the compiler option of our PL/1 modules to NORENT (which
was later
recommended by IBM); RENT was not needed, because our modules are all
naturally reentrant anyway, but that's a different story ...

What we do normally (and what we did again, after returning to PL/1
NORENT, until today):
LOAD only on first call, then store the entry point in static storage in
the caller's CSECT,
and then call using only machine instructions on subsequent calls.

Kind regards

Bernd

[Bernd Oppolzer]

IMO, for DLL support, the RENT compiler option is an absolute requirement;
it makes your Cobol load module reentrant (constructed reentrancy) and
does a lot of other things to the code generation, and DLL calls will
not work
without this. LONGNAME is another prerequisite, IIRC ... same in PL/1.

The RENT linker option, OTOH, is sort of optional ... it tells the
system, that
the module is reentrant and that parallel running tasks or subtasks may use
the same copy in storage concurrently (different from NORENT or REUS),
but the DLL calls will work, even if you don't mark your module as being
RENT.

IMO, if you are not running your programs in a multitasking environment
(batch job only, for example), the DLL calls will internally do a LOAD
of the DLL
only once and then ... like explained in my other mail ... use machine
instructions for
transfer of control. So there is not really a problem.

But, of course, it is better to specify RENT on the binder.

Kind regards

Bernd

[Frank Swarbrick]

Our applications are all either single threaded batch (including batch DL/I) or CICS. Is it correct that under CICS, even without the RENT binder option, only a single instance of (the code portion of) a program is loaded in the CICS region?

In response to someone else's commend, I don't want to justify not using REUS=RENT, only to determine if we should make an effort to, for example, rebind all of our dynamically called subroutines with REUS=RENT, and then use REUS=RENT from this point forward.

Someone else stated that by compiling with the RENT compiler option, it will implicitly bind as RENT as well. My observations tell me that this is not the case.

________________________________
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> on behalf of Bernd Oppolzer <bernd.o...@T-ONLINE.DE>
Sent: Saturday, August 14, 2021 4:14 PM
To: IBM-...@LISTSERV.UA.EDU <IBM-...@LISTSERV.UA.EDU>
Subject: Re: RENT binder option

[Bernd Oppolzer]

Some guessing on my part ... answers below ...

Am 15.08.2021 um 00:36 schrieb Frank Swarbrick:
> Our applications are all either single threaded batch (including batch DL/I) or CICS. Is it correct that under CICS, even without the RENT binder option, only a single instance of (the code portion of) a program is loaded in the CICS region?

yes, I think so. The programs under CICS will fail, if they are not
really reentrant or if they are trying to modify their static areas.

> In response to someone else's commend, I don't want to justify not using REUS=RENT, only to determine if we should make an effort to, for example, rebind all of our dynamically called subroutines with REUS=RENT, and then use REUS=RENT from this point forward.

given your usage patterns, I don't think that you need to relink all
your modules. But you should IMO specify RENT from now on.

> Someone else stated that by compiling with the RENT compiler option, it will implicitly bind as RENT as well. My observations tell me that this is not the case.
>

IMO, RENT and REUS are Linkage Editor attributes added at linkage time;
they are not stored in the object modules, AFAIK;
in contrast to AMODE and RMODE, which are properties of the CSECTs built
by the compilers.
You should see this in your archived binder listings (load module
attributes, at the end of the listing);
if they were marked REENTRANT, you should see it there.

Kind regards

Bernd

[Peter Relson]

The rules for DELETE have existed unchanged for over 40 years (maybe over
50 by now).

For a reentrant module, a use count is incremented in a CDE that is used
for all instances of this job step's use of this module. Each loading task
gets a LLE which itself has a use count. Storage is not freed until the
module use count reaches 0. You'd generally expect the sum of the use
counts in the LLE's to match the use count in the CDE.

For a non-reentrant module, each LOAD gets a new CDE and each loading task
gets a new LLE. The use count in each of these would be 1.

As to "which gets deleted", it would have to match a LOAD done from the
same task now doing the DELETE (as represented in an LLE).
The first matching LLE for the task is going to win. And that, in turn, is
usually going to be the one that is newest for that task. So if that's not
the behavior you want, don't use non-reentrancy this way.

DELETE is "by name". That was undoubtedly easier way back when (the user
"knew" the name, and did not have to keep track of the address), but isn't
a robust way of doing things. some of the FileSystem-based loads are "by
address" which are more flexible in terms of identifying which copy is the
one to delete

But since it really doesn't matter when things are reentrant, and
reentrant forms are preponderant, it is highly unlikely after all this
time that an alternate approach would be provided rather than saying "you
need to make your module reentrant or do things from different tasks" if
somehow you needed the sequence of Load non-reentrant copy 1, Load
non-reentrant copy 2, Delete copy 1.

Just as was the response for the case mentioned in one of the appends
where the use count reached/exceeded the maximum: do something else. In
many cases that "something else" could have been "pre-load the first time"
and then all the other times load+delete, if there was not some reason to
save the result of the first load and just use it subsequently (that being
much faster than load+delete).

Peter Relson
z/OS Core Technology Design

[Paul Gilmartin]

On Sun, 15 Aug 2021 13:25:03 -0400, Peter Relson wrote:

>The rules for DELETE have existed unchanged for over 40 years (maybe over
>50 by now).
>

If I had searched diligently, would I have found those rules documented?

>...

>As to "which gets deleted", it would have to match a LOAD done from the
>same task now doing the DELETE (as represented in an LLE).
>The first matching LLE for the task is going to win. And that, in turn, is
>usually going to be the one that is newest for that task. So if that's not
>the behavior you want, don't use non-reentrancy this way.
>

IOW, probably LIFO.

fork() might add complexity. Does fork() replicate the parent's CSV control
blocks in thee child's process space sufficiently that a child can DELETE
(its image of) a module that was loaded by its parent.

(UNIX provides nice control of descriptors. A descriptor may be given a
close-on-fork attribute; I suspect there's no corresponding DELETE-on-fork
attribute for load modules. And it's customary for a child to close() (its
copy of) descriptors inherited from the parent. I might expect a programmer
likewise to DELETE legacy load modules to reclaim storage.)

>DELETE is "by name". That was undoubtedly easier way back when (the user
>"knew" the name, and did not have to keep track of the address), but isn't
>a robust way of doing things. some of the FileSystem-based loads are "by
>address" which are more flexible in terms of identifying which copy is the
>one to delete

> ...

>Just as was the response for the case mentioned in one of the appends
>where the use count reached/exceeded the maximum: do something else.
>

A colleague has told a war story of an era in which the use count was kept
in 8 bits. He LOADed a module 257 times then DELETEd it once. Then
he did "something else". A conscientious developer would have checked
for overflow and failed the LOAD.

>In many cases that "something else" could have been "pre-load the first time"
>and then all the other times load+delete, if there was not some reason to
>save the result of the first load and just use it subsequently (that being
>much faster than load+delete).
>

It's a pity that Rexx has no built-in LOAD function to support that optimization.
I once found DATE() using several hundred milliseconds per call in a loop
because it was searching my large STEPLIB concatenation for locale support.
WAD.

-- gil

[Bernd Oppolzer]

Many thanks!
Very helpful and clear

[CM Poncelet]

BTW (off topic) REFR, not RENT, if a module's storage may *never* be
modified in any way.

> .

[Steve Smith]

Seems like deja vu. For all practical purposes, RENT and REFR (which
implies RENT) have the same effect (that may be a tautology).

For whatever reasons, RENT & REFR were defined such that they didn't
accurately describe how they were implemented. What the OS wanted was
protected memory for programs (and good programmers want that too). In
effect, both mean that program storage cannot be modified during
execution. But the module attribute definitions go on about the ability
for multiple tasks to simultaneously use the module, or for the ability to
tolerate a refresh. Neither of those things absolutely requires
non-modification, so one wonders why IBM wandered off into those tangents.

On the converse, it's not that hard to write read-only code that is not
reentrant (thread-safe in newspeak). And nothing in z/OS cares a bit...
you just get unpredictable results. Actual reentrancy requires interlocked
access to any shared memory; avoiding variables embedded within the program
module is just the beginning.

The bottom line is that Program Fetch allows RENT modules to be shared,
REUS is just a weird ENQ trick, and otherwise you get multiple copies. I
really don't know if REFR has any effect over RENT. Perhaps it's required
for PLPA modules.

sas

On Sun, Aug 15, 2021 at 5:19 PM CM Poncelet <ponc...@bcs.org.uk> wrote:

> BTW (off topic) REFR, not RENT, if a module's storage may *never* be
> modified in any way.
>
>

[Paul Gilmartin]

On Sun, 15 Aug 2021 18:47:26 -0400, Steve Smith wrote:
> ...

>The bottom line is that Program Fetch allows RENT modules to be shared,
>REUS is just a weird ENQ trick, and otherwise you get multiple copies. I
>really don't know if REFR has any effect over RENT. Perhaps it's required
>for PLPA modules.
>

If REFRPROT is set (in PARMLIB?) REFR objects are loaded in write-protected
storage. REFRPROT is off by default, in an obsession to preserve compatibility
with archaic incorrect code. Alas, REFRPROT has universal scope --
individual programmers have no way to set it for their code.

-- gil

[Seymour J Metz]

IBM originally used REFR in support of the mahine check handler; if you got a parity error in certain refreshable modules then MCH would read in a fresh copy. REFR did not reuire that the module be read-only, just that refreshing it would not cause errors. On modern processors, when there is a good copy of the page on DASD, discarding a page frame with an unrecoverable memory failure is a better solution for the same reliability concern.

As for RENT, if you share a module between a user task and a system task, integrity requires that the user task not be able to modify it, hence key 0.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Steve Smith [sas...@GMAIL.COM]
Sent: Sunday, August 15, 2021 6:47 PM
To: IBM-...@LISTSERV.UA.EDU

Subject: Re: RENT binder option

[CM Poncelet]

Yes, agreed.
 
But programs marked RENT may modify their storage provided they
serialize it by ENQ'ing it, then modifying it, then restoring it to
whatever it was, then DEQ'ing it - but not if in protected storage, IIRC
- whereas REFR prohibits any modification of program storage during
execution. 
 
LPA load modules are or should always be marked RF (REFR).
 
CP

[Paul Gilmartin]

On Mon, 16 Aug 2021 21:38:23 +0000, Seymour J Metz wrote:

>IBM originally used REFR in support of the mahine check handler; if you got a parity error in certain refreshable modules then MCH would read in a fresh copy. REFR did not reuire that the module be read-only, just that refreshing it would not cause errors.
>

That's true of successful operation does not depend on that modified content.
I find it hard to envision such a design.

> ... On modern processors, when there is a good copy of the page on DASD, discarding a page frame with an unrecoverable memory failure is a better solution for the same reliability concern.
>
IOW, the MCH meed only mark the frame as invalid and let paging handle it? (Almost
immediately when the failing instruction is retried.)

-- gil

[Paul Gilmartin]

On Mon, 16 Aug 2021 23:22:33 +0100, CM Poncelet wrote:
>
>  ... REFR prohibits any modification of program storage during
>execution. 
> 
FSVO "prohibits". It's mostly an assertion that the programmer
intended that the program not be so modified.

[Charles Mills]

A program might have a counter in the CSECT that the logic incremented as an aid to debugging. That would S0C4 if storage protected, but the program logic would be fine if the CSECT were refreshed. Granted, something of a stretch.

At the time, paging did not exist.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Monday, August 16, 2021 3:25 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: RENT binder option

On Mon, 16 Aug 2021 21:38:23 +0000, Seymour J Metz wrote:

>IBM originally used REFR in support of the mahine check handler; if you got a parity error in certain refreshable modules then MCH would read in a fresh copy. REFR did not reuire that the module be read-only, just that refreshing it would not cause errors.
>
That's true of successful operation does not depend on that modified content.
I find it hard to envision such a design.

> ... On modern processors, when there is a good copy of the page on DASD, discarding a page frame with an unrecoverable memory failure is a better solution for the same reliability concern.
>
IOW, the MCH meed only mark the frame as invalid and let paging handle it? (Almost
immediately when the failing instruction is retried.)

[Paul Gilmartin]

On Mon, 16 Aug 2021 18:03:50 -0700, Charles Mills wrote:

>A program might have a counter in the CSECT that the logic incremented as an aid to debugging. That would S0C4 if storage protected, but the program logic would be fine if the CSECT were refreshed. Granted, something of a stretch.
>

You need only not consider it an error if the result is wrong.

Otherwise I was considering setting a flag to indicate a tedious
initialization was complete. And closing the timing window in case
the fault occurred during the initialization, and that table might
span multiple pages, and ...

>At the time, paging did not exist.
>

And even before page protection in storage keys?

-- gil

[Seymour J Metz]

Back in OS/360 IBM shipped code that was reentrant but not refreshable. I don't know whether they shipped code that was refreshable but not read only, although I wouldn't be surprised.

Paging existed prior to S/360. In fact, one of the disappointments in the S/360 announcement was that IBM didn't initially include it.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Charles Mills [char...@MCN.ORG]
Sent: Monday, August 16, 2021 9:03 PM

[Seymour J Metz]

Not even that: it's just an assertion that replacing the executing copy with a fresh copy won't cause an error.

However, just because it's legal to write self-modifying reentrant and refreshable code doesn't mean that it's a good idea. :-(

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [0000000433f0781...@LISTSERV.UA.EDU]
Sent: Monday, August 16, 2021 6:36 PM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: RENT binder option

[Seymour J Metz]

I can envision a routine storing footprints for debugging. Cruel, but all very well for a spree.

Yes, except for fixed pages the strategy of discarding and marking invalid the damaged unmodified page frame is simple and elegant, and the page-in will likely be immediate.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [0000000433f0781...@LISTSERV.UA.EDU]

Sent: Monday, August 16, 2021 6:24 PM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: RENT binder option

[Seymour J Metz]

There is no requirement that a self-modifying reentrant program restore the original contents before releasing whatever serialization it uses. However, z/OS will not write changed PLPA pages back to DASD when it steals pages, so self-modifying LPA code is a bad idea.

Whether REFR prevents modification depends on your PARMLIB; by default it's allowed. I don't know of any reason not to switch to REFRPROT.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of CM Poncelet [ponc...@BCS.ORG.UK]
Sent: Monday, August 16, 2021 6:22 PM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: RENT binder option

[CM Poncelet]

FWIW From "MVS Systems Programming" by Dave Elder-Vass (IBM McGRAW-HILL
SERIES, ISBN 0-07-707767-9, 1993):
 
[Section 3.7.2:] "In theory, self-modifying sections are allowed in
re-entrant programs as long as they are preceded by an ENQ, followed by
a DEQ, and restore the modified section to its original value before
issuing the DEQ. These restrictions ensure that only one user can use
the modifying section of code at any one time; however, it introduces
potential delays for widely shared programs and is not recommended."

[Seymour J Metz]

Aftermarket books generally get things wrong; that's why I prefer to use the reference manuals as tutorials. BTW, can you spot what else is wrong with that passage?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of CM Poncelet [ponc...@BCS.ORG.UK]

Sent: Tuesday, August 17, 2021 11:28 PM

[Paul Gilmartin]

On Wed, 18 Aug 2021 08:46:43 +0000, Seymour J Metz wrote:

>Aftermarket books generally get things wrong; that's why I prefer to use the reference manuals as tutorials. BTW, can you spot what else is wrong with that passage?
>

o Should ENQ specify EXC? (Or other locking mechanism such as CS.)

o Should "user" be "job", "thread", or ???

o In some cases such as an in-module RSA, restore is unnecessary.

o ...
________________________________________

>
>FWIW From "MVS Systems Programming" by Dave Elder-Vass (IBM McGRAW-HILL
>SERIES, ISBN 0-07-707767-9, 1993):
>
>[Section 3.7.2:] "In theory, self-modifying sections are allowed in
>re-entrant programs as long as they are preceded by an ENQ, followed by
>a DEQ, and restore the modified section to its original value before
>issuing the DEQ. These restrictions ensure that only one user can use
>the modifying section of code at any one time; however, it introduces
>potential delays for widely shared programs and is not recommended."

-- gil

[Seymour J Metz]

There are lots of serialization techniques that will satisfy the sole requirement of correct parallel execution. CS, latches and locks all come to mind.

I have yet to see a case where a restore is necessary. In most cases a restore would break it.

EXC? That depends on what the code is doing. For a read function you probably want SHR.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [0000000433f0781...@LISTSERV.UA.EDU]
Sent: Wednesday, August 18, 2021 9:02 AM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: RENT binder option

[Barry Lichtenstein]

The linkage editor treated the reusability attributes individually and they could potentially be set independently (NORENT and REFR). The binder treats reusability as a hierarchy, REFR implies RENT, RENT implies SERIALLY REUSABLE, so it will never set them that way. In GOFF object modules and program objects reusability is treated as a single-value field, not individual bits.

The binder simply sets the attributes, there's no attempt by the binder to do anything but complain if the sections (CSECTs) are not consistent with the REUSability option set by the user. If the option specified is more restrictive the binder will give a warning message (IEW2609W) , but still set the module reusability according to the option specified. The default is always REUS=NONE.

Unlike the binder, the linkage editor may honor the module reusability over the option set by the user. Note that while it is only in the PDSDE directory entry of load modules (not in the ESD information of load modules or OBJ object modules), it is available to the binder in the ESD information in program objects and GOFF object modules, as well as in the PDS and PDSE (PMAR) directory entries. And actually the binder can be told to honor the reusability within the module as well, by using the option COMPAT(LKED). Then the binder will issue an informational message (IEW2664I) instead of a warning message, and honor the "downgraded" reusability.

Also the binder will take the most restrictive reusability specified as a simple option name, regardless of order (I know of no other binder options that work this way). So PARM='REFR,NORENT' gets you REFR. To "reset" to non-reentrant you'd have to use the binder syntax REUS(NONE) (or equally REUS=NONE).

To the original DLL question: Languages like C may have data/variables which are writable (residing in the writable-static area, WSA). There was a time and I think in some cases it is still true, where the load point of the module is used by LE to determine that the module was already loaded for a given enclave. LE may use that information to decide whether it should create a new WSA instance associated with that DLL (module), which is shared for the entire LE enclave. Thus not having the module marked as RENT could cause problems, with multiple instances of data/variables are seen in different modules/procedures/functions of the entire DLL application.

On Sun, 15 Aug 2021 18:47:26 -0400 Steve Smith <sas...@GMAIL.COM> wrote:
>
> Seems like deja vu. For all practical purposes, RENT and REFR (which
> implies RENT) have the same effect (that may be a tautology).
>
> For whatever reasons, RENT & REFR were defined such that they didn't
> accurately describe how they were implemented. What the OS wanted was
> protected memory for programs (and good programmers want that too). In
> effect, both mean that program storage cannot be modified during
> execution. But the module attribute definitions go on about the ability
> for multiple tasks to simultaneously use the module, or for the ability to
> tolerate a refresh. Neither of those things absolutely requires
> non-modification, so one wonders why IBM wandered off into those tangents.
>
> On the converse, it's not that hard to write read-only code that is not
> reentrant (thread-safe in newspeak). And nothing in z/OS cares a bit...
> you just get unpredictable results. Actual reentrancy requires interlocked
> access to any shared memory; avoiding variables embedded within the program
> module is just the beginning.
>
> The bottom line is that Program Fetch allows RENT modules to be shared,
> REUS is just a weird ENQ trick, and otherwise you get multiple copies. I
> really don't know if REFR has any effect over RENT. Perhaps it's required
> for PLPA modules.
>
> sas

[Paul Gilmartin]

On Wed, 25 Aug 2021 15:56:33 -0500, Barry Lichtenstein wrote:

>... (NORENT and REFR). The binder treats reusability as a hierarchy, REFR implies RENT, ...

They saved a bit by allowing the reusability to have 4 values instead of 8.
(NORENT and REFR) could have made sense if a programmer had
relied on them to serialize access to shared data areas. Well, no. CSV
would simply load another instance.

>On Sun, 15 Aug 2021 18:47:26 -0400 Steve Smith wrote:
>>
>> Seems like deja vu. For all practical purposes, RENT and REFR (which
>> implies RENT) have the same effect (that may be a tautology).
>>

>> For whatever reasons, RENT & REFR ... or for the ability to

>> tolerate a refresh. Neither of those things absolutely requires
>> non-modification, so one wonders why IBM wandered off into those tangents.
>>

I'm trying to envision what is needed for modified code to tolerate a
refresh. Field the protection exception; proceed with the refresh;
and re-drive the failed operation ab ovo? I suppose.

-- gil

[CM Poncelet]

IIRC The page(s) of an LMOD marked REFR can be stolen without having
first to back it up to cache, because it can be REFReshed from cache (or
DASD) and continue to execute as if its page(s) had not been stolen -
e.g. in the PLPA. If it modified itself, it would hit a S0C4-4. AFAIK A
backup/swap-out would be needed if it was marked RENT but not REFR.

> .

[Jim Mulder]

YDNRC. In general, the frame steal code has no knowledge
that a frame contains a program, or that the program
is REFR. The only exception to that is the PLPA and EPLPA
virtual storage ranges, for which the frame steal code does
steal without paging out, effectively treating everything in
those ranges as conceptually REFR for stealing purposes,
regardless of the load module attributes.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY

"IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU> wrote on
08/25/2021 09:10:04 PM:

> From: "CM Poncelet" <ponc...@BCS.ORG.UK>
> To: IBM-...@LISTSERV.UA.EDU
> Date: 08/25/2021 11:21 PM
> Subject: Re: RENT binder option

> Sent by: "IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU>
>
> IIRC The page(s) of an LMOD marked REFR can be stolen without having
> first to back it up to cache, because it can be REFReshed from cache (or
> DASD) and continue to execute as if its page(s) had not been stolen -
> e.g. in the PLPA. If it modified itself, it would hit a S0C4-4. AFAIK A
> backup/swap-out would be needed if it was marked RENT but not REFR.

[Greg Price]

On 8/26/2021 1:54 PM, Jim Mulder wrote:
> The only exception to that is the PLPA and EPLPA
> virtual storage ranges, for which the frame steal code does
> steal without paging out, effectively treating everything in
> those ranges as conceptually REFR for stealing purposes,
> regardless of the load module attributes.

I have a memory that decades ago a CLPA failed because at least 1 PLPA
module was not linked with RENT.

Anyone know if a non-RENT marked PLPA module would stop a CLPA these days?

TIA.

Cheers,
Greg

[Seymour J Metz]

REUS and REFR would give you the serialization if the binder treated it the same as the linkage editor, but IMHO there are much better ways to serialize.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [0000000433f0781...@LISTSERV.UA.EDU]

Sent: Wednesday, August 25, 2021 5:41 PM
To: IBM-...@LISTSERV.UA.EDU

Subject: Re: RENT binder option

[Seymour J Metz]

Even the linkage editor had a hierarchy: nonreusable, serially reusable and reentrant. The difference is that in the binder REFR is part of the hierarchy, while in the linkage editor it is independent.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Barry Lichtenstein [bar...@US.IBM.COM]
Sent: Wednesday, August 25, 2021 4:56 PM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: RENT binder option

[Peter Relson]

>LPA load modules are or should always be marked RF (REFR).

LPA modules are considered refreshable. There is no reason to mark them
so, but it will do no harm if you do.

<snip>

IIRC The page(s) of an LMOD marked REFR can be stolen without having
first to back it up to cache, because it can be REFReshed from cache (or
DASD) and continue to execute as if its page(s) had not been stolen -
e.g. in the PLPA. If it modified itself, it would hit a S0C4-4. AFAIK A
backup/swap-out would be needed if it was marked RENT but not REFR.

</snip>

The description related to REFR is theoretically true but z/OS (and its
predecessors) implemented this type of processing only for PLPA (maybe
MLPA too).

Peter Relson
z/OS Core Technology Design

[Barry Lichtenstein]

Shmuel you are correct. If you code RENT the linkage editor also sets REUS, and if you set REFR it does not set the others. However you can also independently turn on or off REUS in the linkage editor. The binder enforces that only one reusability attribute is set. (Interestingly the linkage editor table of incompatible options has always shown REUS and RENT as incompatible.)

On Thu, 26 Aug 2021 12:37:17 +0000 Seymour J Metz <sme...@GMU.EDU> wrote:
> Even the linkage editor had a hierarchy: nonreusable, serially reusable and reentrant. The difference is that in the binder REFR is part of the hierarchy, while in the linkage edi
tor it is independent.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3

[Seymour J Metz]

REFR precedes OS/VS. In OS/360 MVS with MCH, the REFR bit affected the handling of machine checks. As I recall, the MCH could refresh transient SVC routines and refreshable nucleus CSECTs. With OS/VS2 R1 (SVS), there were no more SVC transient areas, but the MCH could still reload refreshable nucleus CSECTs from SYS1.ASRLIB. I don't recall when the ASRLIB processing went away.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Peter Relson [rel...@US.IBM.COM]
Sent: Thursday, August 26, 2021 10:09 AM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: RENT binder option

[CM Poncelet]

According to my OS/390 Collection March 1999 Version 2 Release 7.0:

RENT: MVS *protects your module's virtual storage so that your module
cannot be modified* - and REFR implies RENT.
 
See attached.
 
Cheers, Chris Poncelet (retired sysprog consultant)

[CM Poncelet]

According to my OS/390 Collection March 1999 Version 2 Release 7.0:

RENT: MVS *protects your module's virtual storage so that your module
cannot be modified* - and REFR implies RENT.
 

See attached (this time without Unicode formatting <g>.)

 
Cheers, Chris Poncelet (retired sysprog consultant)



On 26/08/2021 04:54, Jim Mulder wrote:

[Paul Gilmartin]

On Fri, 27 Aug 2021 01:05:18 +0100, CM Poncelet wrote:

>According to my OS/390 Collection March 1999 Version 2 Release 7.0:
>
>RENT: MVS *protects your module's virtual storage so that your module
>cannot be modified* - and REFR implies RENT.
> 

Feels like a doc error. Submit an RCF.

Which book? What does z/OS v2r4 say?

>See attached.
> 
Damn, that favicon is small. Can't even tell what it's supposed to be.

-- gil

[Seymour J Metz]

Incorrect and out of context.

In general, there is a difference between the processing of reusability attributes between the linkage editor and binder. Also, the subpool used depends not only on the reusability attribute but also on the authorization status of the concatenation.

See also REFRPROT.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of CM Poncelet [ponc...@BCS.ORG.UK]

Sent: Thursday, August 26, 2021 8:12 PM
To: IBM-...@LISTSERV.UA.EDU

[CM Poncelet]

The favicon is a .txt file containing a copy of IBM's definitions of
REUS, RENT, REFR - and of what they mean and do, from the OS/390 V2R7 CD
collection. 
 
As we say in French (about REUS, RENT, REFR): "on a changé tout ça". ;-)
 
I reattach it. Click on it, if it is not displayed automatically.
 
Cheers, Chris poncelet (retired etc.)

> .

[Seymour J Metz]

No, it is a text file containing one of IBM's old descriptions of the reusability option in *the binder* and in now way makes any claim about the linkage editor. Further, it is incorrect: RENT by itself is not enough to protect a module from modification. Contrast wit Module reusability at <https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa231393/$file/ieab100_v2r4.pdf#page=55> and REUS: Reusability options at <https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa231393/$file/ieab100_v2r4.pdf#page=115> in z/OS Version 2 Release 4 MVS Program Management: User's Guide and Reference, SA23-1393-40.

There is still a minor error: "Therefore, refreshable modules must not modify themselves in any way" is a non sequitur.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of CM Poncelet [ponc...@BCS.ORG.UK]

Sent: Friday, August 27, 2021 6:46 AM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: RENT binder option

[Barry Lichtenstein]

The binder and linkage editor manuals have attempted to describe the load-time behaviors of modules according to the link-time parameters. (Similarly for the binder FETCHOPT). This is somewhat unfortunate, as while it is reasonable to expect some description of the options in those manuals, the behaviors are going to depend on the system on which the module is being executed. The binder really is just merely setting the bits in the directory.

That said the REUS options, along with AMODE and RMODE, are surprisingly confusing, especially with their linkage editor history. The section of the binder (Program Management: User's Guide and Reference), Appendix B -> Migrating from the linkage editor to the binder -> Binder processing differences from the linkage editor, does a pretty good job of explaining all this:

https://www.ibm.com/docs/en/zos/2.4.0?topic=binder-processing-differences-from-linkage-editor

Lastly that's certainly a long-standing error in the publication! "The refreshable attribute is negated if any input modules are not refreshable." That's linkage editor behavior, and it is only true with the binder if COMPAT(LKED) is specified.

In fact in the linkage editor that is the behavior of all the reusability options (I'm looking at the MVS/ESA Linkage Editor and Loader's Guide Version 3 Release 1, SC26-4510-1, Second Edition June 1989): (** highlighting ** is mine) In reference to the OP statement ("Someone else stated that by compiling with the RENT compiler option, it will implicitly bind as RENT as well. My observations tell me that this is not the case."), note that none of the INCLUDEd modules attributes _set_ the reusability on, they only may turn it off.

Reusability Attributes

Either one of two attributes may be specified to denote the reusability of a module. (Reusability means that the same copy of a load module can be used by more than one task either concurrently or one at a time.) The reusability attributes are reenterable and serially reusable; if neither is specified, the module is not reusable and a fresh copy must be brought into virtual storage before another task can use the module.
** The linkage editor only stores the attribute in the directory entry; it does not check whether the module is really reenterable or serially reusable. **
A reenterable module is automatically assigned the reusable attribute. However, a reusable module is not also defined as reenterable; it is reusable only.

Reenterable: A module with the reenterable attribute can be executed by more than one task at a time; that is, a task may begin executing a reenterable module before a previous task has finished executing it. This type of module cannot be modified by itself or by any other module during execution. If a module is to be reenterable, all the control sections within the module must be reenterable.
**If the reenterable attribute is specified, and any load modules that are not reenterable become a part of the input to the linkage editor, the attribute is negated.**

Serially Reusable: A module with the serially reusable attribute can be executed by only one task at a time; that is, a task may not begin executing a serially reusable module before a previous task has finished executing it. This type of module must initialize itself and/or restore any instructions or data in the module altered during execution. If a module is to be serially reusable, all its control sections must be either serially reusable or reenterable.
** If the serially reusable attribute is specified, and any load modules that are neither serially reusable nor reenterable become a part of the input to the linkage editor, the serially reusable attribute is negated. **

Refreshable Attribute:

A module with the refreshable attribute can be replaced by a new copy during execution by a recovery management routine without changing either the sequence or results of processing. This type of module cannot be modified by
itself or by any other module during execution. The linkage editor only stores the attribute in the directory entry; it does not check whether the module is refreshable. If a module is to be refreshable, all the control sections within it must be refreshable.
** If the refreshable attribute is specified, and any load modules that are not refreshable become a part of the input to the linkage editor, the attribute is negated. **

Barry L

On Fri, 27 Aug 2021 11:38:05 +0000 Seymour J Metz <sme...@GMU.EDU> wrote:
> No, it is a text file containing one of IBM's old descriptions of the reusability option in *the binder* and in now way makes any claim about the linkage editor. Further, it is
incorrect: RENT by itself is not enough to protect a module from modification. Contrast wit Module reusability at <https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV
2R4sa231393/$file/ieab100_v2r4.pdf#page=55> and REUS: Reusability options at <https://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sa231393/$file/ieab100_v2r4.pdf#pa
ge=115> in z/OS Version 2 Release 4 MVS Program Management: User's Guide and Reference, SA23-1393-40.
>
> There is still a minor error: "Therefore, refreshable modules must not modify themselves in any way" is a non sequitur.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3

[Peter Relson]

<snip>
RENT: MVS protects your module's virtual storage so that your module
cannot be modified - and REFR implies RENT.
</snip>

z/OS ignores "refreshable" except when REFRPROT is in effect.
Thus if "REFR implies RENT" then it is important that the RENT indicator
be set when REFR is specified without RENT. I presume that that is what
happens, but I have not tried it.

"cannot be modified" is all a matter of degree. Anything can be modified
if you are authorized enough. Some of the rules that apply (the rules are
more complex, so this is not completely accurate):
-- RENT modules not from an APF-authorized library are not placed in key 0
storage so they "can" be modified by an unauthorized program
-- RENT modules from an APF-authorized library are placed in key 0 storage
so they "can" be modified by a key 0 program. The same is true for a
TCBKEY9 task
-- REFR modules with REFPROT are page-protected. When page-fixed, they
"can" be modified by using real addresses

Peter Relson
z/OS Core Technology Design

[CM Poncelet]

ROTFL

[Lennie Dymoke-Bradshaw]

I realise I may be inviting a "YDNRC" but I think the REFRPROT (not REFPROT)
option only protects entire pages of a module. If a module is 5K long then
the last 1K is unprotected. Always sounded like an opportunity for
exploitation; bit like a buffer overrun.

Lennie Dymoke-Bradshaw
https://rsclweb.com
'Dance like no one is watching. Encrypt like everyone is.'

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of
Peter Relson
Sent: 28 August 2021 15:02
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: RENT binder option

[Paul Gilmartin]

On Sun, 29 Aug 2021 11:59:12 +0100, Lennie Dymoke-Bradshaw wrote:

>I realise I may be inviting a "YDNRC" but I think the REFRPROT (not REFPROT)
>option only protects entire pages of a module.
>

Me, too.

> ...If a module is 5K long then

>the last 1K is unprotected. Always sounded like an opportunity for
>exploitation; bit like a buffer overrun.
>

That would necessarily be inadvertent. It should be impossible for
untrustworthy code to modify content of an Authorized address
space.

FSVO "should". IBM has deemed storage/paging optimization to
have greater than checking for bad code.

-- gil

[Seymour J Metz]

There is always a tradeoff in documentation among conflicting goals.

Ease of maintenance. This requires putting technical details in a single place.

Ease of use. This requires reducing the need to refer to other manuals for technical details.

Accuracy. This is tied into ease of maintenance.

Legibility. It may be difficult to construct text that is both accurate and readable.

Cost; a good SME or technical writer is expensive

Currency. Good documentation takes time, which may be contrained.

I believe that the move away from DCF-based tools has exacerbated the problem.

I vaguely recall a table showing storage attributes associated with various types of fetch, including subpool, key, fetch protect and page protect.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Barry Lichtenstein [bar...@US.IBM.COM]

Sent: Friday, August 27, 2021 1:11 PM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: RENT binder option

[Joel C. Ewing]

If REFRPROT is used, the affected module is loaded into a key-0 storage
pool, so even if a partial page at the end of the module is not "page
protected", it is still key-0-protected and only a program running in
key 0 can modify it. 

A program running in key-0 that could directly modify the final partial
page could also in theory page-fix any of the full pages of the module,
bypass any "page protection" and update a protected full page as well,
so if you allow malicious programs to run in key-0, as always all bets
are off.

Since deliberate malicious modification by key-0 code is always
possible, this partial page additional exposure is probably minimal.  
If you wanted to rule out the possibility of any accidental modification
by key-0 code of the entire module, the simplest solution would be to
force the length of  REFR modules to a multiple of 4KiB so there are no
partial pages.  Maybe this size rounding should be an option for REFR
modules now that real-storage and virtual-storage constraints are less
of an issue for many installations.
    Joel C. Ewing

--
Joel C. Ewing

[CM Poncelet]

The bottom line is that the integrity/security of a current OS cannot be
reduced to a lower integrity/security level by upgrading it to a new OS
- as e.g. upgrading OS/390 to z/OS could not result in z/OS then being
less secure than OS/390.
 
Hence the argument that the integrity/security provided by 'REUS, RENT,
REFR' in OS/390 does not apply to z/OS is absurd - as this would imply
that z/OS is less secure than OS/390.
 
BTW AFAIK It is programs running in key 0-7, not only in key 0, that are
storage protected. If memory serves, CICS (and/or perhaps IMS) executes
in key-7 not key-0.
 
AFAIK2 LMOD storage is always allocated in multiples of 4K pages. If so,
a 5K module would be allocated 2 pages of 4K each - and both its 4K
pages (total 8K) would then be OS-protected.

[Seymour J Metz]

I believe that with REFRPROT, a 5KiB module with RENT will be loaded into two pages both of which are page protected.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Joel C. Ewing [jce.e...@COX.NET]
Sent: Sunday, August 29, 2021 7:23 PM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: RENT binder option

If REFRPROT is used, the affected module is loaded into a key-0 storage
pool, so even if a partial page at the end of the module is not "page
protected", it is still key-0-protected and only a program running in
key 0 can modify it.

A program running in key-0 that could directly modify the final partial
page could also in theory page-fix any of the full pages of the module,
bypass any "page protection" and update a protected full page as well,
so if you allow malicious programs to run in key-0, as always all bets
are off.

Since deliberate malicious modification by key-0 code is always
possible, this partial page additional exposure is probably minimal.
If you wanted to rule out the possibility of any accidental modification
by key-0 code of the entire module, the simplest solution would be to
force the length of REFR modules to a multiple of 4KiB so there are no
partial pages. Maybe this size rounding should be an option for REFR
modules now that real-storage and virtual-storage constraints are less
of an issue for many installations.
Joel C. Ewing

On 8/29/21 5:59 AM, Lennie Dymoke-Bradshaw wrote:
> I realise I may be inviting a "YDNRC" but I think the REFRPROT (not REFPROT)
> option only protects entire pages of a module. If a module is 5K long then
> the last 1K is unprotected. Always sounded like an opportunity for
> exploitation; bit like a buffer overrun.
>
> Lennie Dymoke-Bradshaw

> https://secure-web.cisco.com/1NLk9V3hjcFNgG5yDTKUzJ7MMYjPWfVOXbh9pmBJmYPAWtUsU8O3yKS6Qnp31A7uj0iKtP3bUftowH7LdTjtNu026EqE_5oa5FD2zUi5vnEIou_uesNvX2wKo5izNuD3daV5dAq6OL6ETajAVIpZxKNlpOZJpl9tV206FBvIP0VXbxQE1Rbm8c9b495qFqEPWKH948RvvGeRP61mA3nVorH6z-wh48-PZt1F1jRQ8ogjND-dmVwFmFdx3Pr46k7VWjw6m-jNVx0w5spKChr9g_92n1m5hNhVbQk70N291DDHu7pT-cwSbFuZ5hw85i4IAfaaSXm5aMneq9UIMWf2e9OPqwU487PKoEQWNtOmdc6_y4Ug0dfujRHlGhIs-xrems9KYt8NaEvFpVj2PdISp3E4luDHhtc0qm4ab5OQL_3x5N1dkBtDpkyVRD1EyR78U/https%3A%2F%2Frsclweb.com

[Paul Gilmartin]

On Mon, 30 Aug 2021 03:33:36 +0000, Seymour J Metz wrote:

>I believe that with REFRPROT, a 5KiB module with RENT will be loaded into two pages both of which are page protected.
>

RENT does not imply REFR. Doesn't REFRPROT protect only, well, REFR?

Aren't pages far larger than 4KiB nowadays?

Regardless if, as some believe, pages partially occupied by REFR objects are
unprotected, that strikes me as a false economy. What's the point? To be able
to use the remainder of such pages for non-REFR code, or for data?

-- gil

[Seymour J Metz]

Sorry, typo; should be "I believe that with REFRPROT, a 5KiB module with REFR will be loaded into two pages both of which are page protected.".

There are large pages, but they are not the norm and come with some restrictions.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [0000000433f0781...@LISTSERV.UA.EDU]
Sent: Monday, August 30, 2021 6:27 AM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: RENT binder option

[Lennie Dymoke-Bradshaw]

Your statement is not supported by what I find in the z/OS 2.4
documentation.
https://www.ibm.com/docs/en/zos/2.4.0?topic=lpa-using-refrprot-statement

Lennie Dymoke-Bradshaw
https://rsclweb.com

'Dance like no one is watching. Encrypt like everyone is.'


-----Original Message-----

[Andrew Rowley]

On 30/08/2021 11:59 am, CM Poncelet wrote:
> The bottom line is that the integrity/security of a current OS cannot be
> reduced to a lower integrity/security level by upgrading it to a new OS
> - as e.g. upgrading OS/390 to z/OS could not result in z/OS then being
> less secure than OS/390.
>
> Hence the argument that the integrity/security provided by 'REUS, RENT,
> REFR' in OS/390 does not apply to z/OS is absurd - as this would imply
> that z/OS is less secure than OS/390.

I don't think REUS, RENT, REFR are intended to contribute to security at
all. All these attributes are is an indication of when a new copy of a
module needs to be loaded, and when an existing copy can be shared.

--
Andrew Rowley
Black Hill Software

[Jim Mulder]

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.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY

"IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU> wrote on
08/30/2021 08:41:39 AM:

> From: "Andrew Rowley" <and...@BLACKHILLSOFTWARE.COM>
> To: IBM-...@LISTSERV.UA.EDU
> Date: 08/30/2021 09:43 AM
> Subject: Re: RENT binder option

[Paul Gilmartin]

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

[Jim Mulder]

New York responds, courteously.

On a test system, you may specify the undocumented
CsvSP252RoundUp TRAPS name in DIAGxx. For a module
being loaded into subpool 252, that will round the length up to
a 4K multiple.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY


"IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU> wrote on

08/30/2021 12:00:52 PM:

> From: "Paul Gilmartin" <0000000433f0781...@LISTSERV.UA.EDU>
> To: IBM-...@LISTSERV.UA.EDU
> Date: 08/30/2021 01:00 PM
> Subject: Re: RENT binder option
> Sent by: "IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU>
>

[Lennie Dymoke-Bradshaw]

*****
5-star response
Lennie

[Tom Brennan]

Why does this remind me of that scene in "War Games"? :)

Malvin: I can't believe it, Jim. That girl's standing over there
listening and you're telling him about our back doors?
Jim: [yelling] Mister Potato Head! MISTER POTATO HEAD!! Back doors are
not secrets!
Malvin: Yeah, but Jim, you're giving away all our best tricks!
Jim: They're not tricks.

[Paul Gilmartin]

On Mon, 30 Aug 2021 13:10:50 -0400, Jim Mulder wrote:
>
> On a test system, you may specify the undocumented
>CsvSP252RoundUp TRAPS name in DIAGxx. For a module
>being loaded into subpool 252, that will round the length up to
>a 4K multiple.
>

Document it. What's IBM trying to protect via obscurantism?
(Cf. Tom Brennan's ply.)

What's the harm in specifying CsvSP252RoundUp TRAPS on a
production system? I suspect:

o Squandering a couple slack KiB for each module loaded.

o Possible program checks in poorly implemented vendor products.
Conscientious vendors should be willingly repair those (what
would IBM do?)

o RoundUp is a suspected carcinogen.

[Schmutzok, Mike , US - Georgia]

The movie, 1776? lol

On the vote for Independence...

"New York abstains, courteously."

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Jim Mulder
Sent: Monday, August 30, 2021 1:11 PM
To: IBM-...@LISTSERV.UA.EDU

Subject: Re: RENT binder option

⚠ EXTERNAL MESSAGE – Think Before You Click

[Charles Mills]

> RoundUp is a suspected carcinogen.

Should have referenced a bug killer rather than a weed killer, no? CsvSP252BlackFlag?

> Document it. What's IBM trying to protect via obscurantism?

Not having to document it LOL. I suppose not having to provide it on an ongoing, "upward compatible" basis.

Seriously, I agree with @Gil. Wasting a few bytes should be the default, not leaving a few bytes unprotected.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Monday, August 30, 2021 1:41 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: RENT binder option

On Mon, 30 Aug 2021 13:10:50 -0400, Jim Mulder wrote:
>
> On a test system, you may specify the undocumented
>CsvSP252RoundUp TRAPS name in DIAGxx. For a module
>being loaded into subpool 252, that will round the length up to
>a 4K multiple.
>
Document it. What's IBM trying to protect via obscurantism?
(Cf. Tom Brennan's ply.)

What's the harm in specifying CsvSP252RoundUp TRAPS on a
production system? I suspect:

o Squandering a couple slack KiB for each module loaded.

o Possible program checks in poorly implemented vendor products.
Conscientious vendors should be willingly repair those (what
would IBM do?)

o RoundUp is a suspected carcinogen.

[Gord Tomlin]

On 2021-08-30 17:28 PM, Charles Mills wrote:
> Seriously, I agree with @Gil. Wasting a few bytes should be the default, not leaving a few bytes unprotected.

It's a bit of a double-edged sword...

The behavior of REFRPROT is clearly stated in documentation:
https://www.ibm.com/docs/en/zos/2.4.0?topic=lpa-using-refrprot-statement

If it is desired to have all parts of a program be page protected, I
suggest that it is fairly straightforward task to pad a program out to
exactly occupy full pages.

To automatically extend all REFR modules to a multiple of 4K by default
on a real system could result in much more than "wasting a few bytes".
To put things in perspective, I have seen customer systems with over two
hundred subsystems in their SSCVT chain (yes, I know the SSCVTs
themselves are not programs, but they do have programs related to them),
or as many as seven ISV products front-ending the same SVC. There can be
a lot of products adding REFR modules to DLPA or CSA, and all those "few
bytes" can add up.

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

[Tom Brennan]

I don't know what Cf. or ply. mean around my name, but I was just joking
around with someone from IBM who is super helpful here and happens to
have the same name as the guy in the movie.

[Andrew Rowley]

On 30/08/2021 11:49 pm, 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.

That is true, but it is a consequence of marking it RENT, not the
purpose. Are RENT modules from authorized libraries more secure than
non-RENT modules?

It actually implies the opposite - RENT modules need additional
protection. When you execute a RENT module, you are executing something
that may have been loaded weeks ago, and without storage protection may
have been deliberately or accidentally modified. If a module is not
marked RENT, you get a nice freshly loaded copy every time.

[Jim Mulder]

For system integrity, programs which run in an
authorized state need to be protected from modification by
unauthorized programs. Authorized programs which can run in
an address space where unauthorized programs are also running
need to be RENT for this purpose. So in that case, it is
at least a purpose of marking them RENT.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY


"IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU> wrote on

08/30/2021 07:23:00 PM:

> From: "Andrew Rowley" <and...@BLACKHILLSOFTWARE.COM>
> To: IBM-...@LISTSERV.UA.EDU
> Date: 08/30/2021 08:25 PM
> Subject: Re: RENT binder option
> Sent by: "IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU>
>

[Jim Mulder]

The undocumented TRAP name in DIAGxx was something I added
at very low cost for my use. For documented things, we have a
more extensive (and thus costly) process, including:
- Design documents
- Design document reviews
- Formal testing
- Interface Change Notification to software vendors
- T3 Education for ESP customers
- Service Education for Level2/Level3

And if we are changing a default behavior:
- Migration Actions

If I wanted to spend some serious $$$ on protecting
the partial pages, I would look into creating a new subpool
specifically for REFR modules, and changing IEWFETCH and
the PMLoader to use real addresses for doing relocation (as the
PMLoader does during page fault processing for a
program object which uses deferred loading).

Do you know all of the places in the documentation that
need to be updated when adding a new subpool? I don't.
But I have come across places that were missed when other
subpools were added.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY

"IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU> wrote on

08/30/2021 05:28:50 PM:

> From: "Charles Mills" <char...@MCN.ORG>
> To: IBM-...@LISTSERV.UA.EDU

> Date: 08/30/2021 08:51 PM
> Subject: Re: RENT binder option

> Sent by: "IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU>
>

[Jim Mulder]

Yes, I know the lines from that show from having
played in the orchestra for it here:

https://countyplayers.org/icpdb/shows/0502.html

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY

"IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU> wrote on

08/30/2021 05:12:37 PM:

> From: "Schmutzok, Mike (US - Georgia)" <000002dd6b12f291-dmarc-
> req...@LISTSERV.UA.EDU>
> To: IBM-...@LISTSERV.UA.EDU

> Date: 08/30/2021 09:32 PM
> Subject: Re: RENT binder option
> Sent by: "IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU>
>

> The movie, 1776? lol
>
> On the vote for Independence...
>
> "New York abstains, courteously."
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU
> ] On Behalf Of Jim Mulder
> Sent: Monday, August 30, 2021 1:11 PM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: RENT binder option
>
> ⚠ EXTERNAL MESSAGE – Think Before You Click
>
>
>
> New York responds, courteously.

[David Spiegel]

Hi Andrew,
You said: "... If a module is not marked RENT, you get a nice freshly
loaded copy every time. ..."
Is that true if a module is (from a LNKLSTd PDS and the module is)
cached by VLF?

Thanks and regards,
David

On 2021-08-30 19:23, Andrew Rowley wrote:
> On 30/08/2021 11:49 pm, 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.
> That is true, but it is a consequence of marking it RENT, not the
> purpose. Are RENT modules from authorized libraries more secure than
> non-RENT modules?
>
> It actually implies the opposite - RENT modules need additional
> protection. When you execute a RENT module, you are executing
> something that may have been loaded weeks ago, and without storage
> protection may have been deliberately or accidentally modified. If a
> module is not marked RENT, you get a nice freshly loaded copy every time.
>

[Seymour J Metz]

You don't get a fresh copy if it's serially reusable.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Andrew Rowley [and...@BLACKHILLSOFTWARE.COM]
Sent: Monday, August 30, 2021 7:23 PM
To: IBM-...@LISTSERV.UA.EDU

Subject: Re: RENT binder option

[CM Poncelet]

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.

> .

[Peter Relson]

Compatibility is a concern. That is why the default will not change. It is
not only a question of "a few bytes".

There are programs that break if everything gets rounded to page
multiples.
Maybe those programs are wrong and should be fixed. But that is not our
call.

Peter Relson
z/OS Core Technology Design

[Peter Relson]

<snip>

Hence, the OS allocates whole - not partial - 4K pages to a load module
(LMOD)

...

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.

</snip>

This logic is flawed and the conclusions are untrue.
This relates to the fact that REFRPROT only deals with the full 4K pages
within a module.

[Peter Relson]

FWIW, REFRPROT accomplishes two things:
use of key 0 storage for reentrant modules whether from an authorized
concatenation or not (aside from the cases for which key 0 storage is not
used when it is RENT even from an authorized concatenation, such as within
TSO TEST when the requestor is not authorized)
page-protection of the whole pages within those modules

The former is probably more of frequent interest RAS-wise than the latter,
but when the latter comes into play (key 0 module being overlaid) the
ramifications can be far more serious.

[Greg Price]

On 8/31/2021 11:35 AM, Jim Mulder wrote:
> Yes, I know the lines from that show from having
> played in the orchestra for it here:
>
> https://countyplayers.org/icpdb/shows/0502.html

I expect you chatted about diagnostic techniques with Dave during breaks
in rehearsal...

O-O
\_/

[Jim Mulder]

This is not the XDC Dave Cole. Dave Cole the musician
was an MVS developer who worked on TSO/E (and was
the developer of the PRINTDS command) and MVS/APPC.
We did not discuss diagnostic techniques, but we did create
a design that would have allowed the systems in a sysplex
to safely share MVS/APPC TP Profile and Side Info
data sets, while waiting in line for several hours to get into
the "Back To The Future" ride at Universal Studios in
Orlando. Unfortunately, the funding to implement that
design never happened.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY

"IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU> wrote on

08/31/2021 10:26:08 AM:

> From: "Greg Price" <greg....@OPTUSNET.COM.AU>
> To: IBM-...@LISTSERV.UA.EDU
> Date: 08/31/2021 12:44 PM
> Subject: Re: RENT binder option
> Sent by: "IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU>
>

[Bill Hitefield]

Is this the Dave Cole who wrote "Boney Fingers" - many years ago?

Bill Hitefield

> -----Original Message-----
> From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On
> Behalf Of Jim Mulder

> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fco
> > >
> untyplayers.org%2Ficpdb%2Fshows%2F0502.html&amp;data=04%7C01%7C
> Bill.
> > > Hitefield%40DINO-
> SOFTWARE.COM%7Cf4aada48c5ac4698313708d96ca03f25%7Cb
> > >
> e5c5b1debb343f3a3641e98fd405647%7C0%7C0%7C637660257773751296%
> 7CUnkno
> > >
> wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> haWw
> > >
> iLCJXVCI6Mn0%3D%7C1000&amp;sdata=KgdiC0baOEOdmWgn7xrBDzcKccd
> Uk%2F4An
> > > 1b7jFwGpVs%3D&amp;reserved=0

[Jim Mulder]

For *my* information?

Contents Supervisor uses GETMAIN to obtain
module storage. VSM is quite happy to allocate
partial pages. It has been thus since before my time at
IBM (42 years).

I have to go with what Jor-el says at time
0:43 in this clip:

https://www.youtube.com/watch?v=zUmMeS2c4Uw

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY


"IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU> wrote on

08/30/2021 11:29:35 PM:

> From: "CM Poncelet" <ponc...@BCS.ORG.UK>
> To: IBM-...@LISTSERV.UA.EDU
> Date: 08/31/2021 12:26 PM
> Subject: Re: RENT binder option
> Sent by: "IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU>
>

> 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.

[Seymour J Metz]

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 [IBM-...@LISTSERV.UA.EDU] on behalf of CM Poncelet [ponc...@BCS.ORG.UK]
Sent: Monday, August 30, 2021 11:29 PM
To: IBM-...@LISTSERV.UA.EDU

Subject: Re: RENT binder option

[CM Poncelet]

"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.

[Jim Mulder]

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" <IBM-...@LISTSERV.UA.EDU> wrote on
08/31/2021 11:23:11 PM:

> From: "CM Poncelet" <ponc...@BCS.ORG.UK>
> To: IBM-...@LISTSERV.UA.EDU

[Peter Relson]

CM Poncelet wrote
<snip>

The LP (load point) addresses of LMODs always end with x'000' (i.e.
page-aligned)

</snip>

wanna bet?

If this is what you have seen in all the dumps you have looked at, then
you need to look at more dumps.

Peter Relson
z/OS Core Technology Design

[Seymour J Metz]

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 [IBM-...@LISTSERV.UA.EDU] on behalf of CM Poncelet [ponc...@BCS.ORG.UK]

Sent: Tuesday, August 31, 2021 11:23 PM

[Paul Gilmartin]

On Wed, 1 Sep 2021 01:44:44 -0400, Jim Mulder wrote:

> As we have already discussed, program objects do get
>rounded up to 4k multiples. Load modules do not.
>

So for program objects REFRPROT follows POLA.

∎

Both ends rounded?

[Paul Gilmartin]

On Wed, 1 Sep 2021 01:44:44 -0400, Jim Mulder wrote:

> As we have already discussed, program objects do get
>rounded up to 4k multiples. Load modules do not.

> ...

On Mon, 30 Aug 2021 18:11:07 -0400, Gord Tomlin wrote:

>On 2021-08-30 17:28 PM, Charles Mills wrote:

>> Seriously, I agree with @Gil. Wasting a few bytes should be the default, not leaving a few bytes unprotected.

> ...

>To automatically extend all REFR modules to a multiple of 4K by default
>on a real system could result in much more than "wasting a few bytes".
>To put things in perspective, I have seen customer systems with over two

>hundred subsystems i..
>--
Does this mean that conversion to PDSE, implying program objects, implyig
4Ki rounding would adversely affect them?

[Jim Mulder]

Some considerations for conversion to
program objects are documented here:

https://www.ibm.com/docs/en/zos/2.4.0?topic=objects-what-should-be-converted-program

The cases where the program object loader
rounds up the size to a 4K multiple and forces 4K
alignment (without alignment being requested by a
binder option) are those in which DIV is used to
read the program directly into the target storage.
That is an implementation detail and is thus subject
to change, and thus would not be documented.
Obviously, a LOAD where the caller specifies the
target address is a case where rounding and
alignment are not done.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY

"IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU> wrote on
09/01/2021 11:04:15 AM:

> From: "Paul Gilmartin" <0000000433f0781...@LISTSERV.UA.EDU>
> To: IBM-...@LISTSERV.UA.EDU

> Date: 09/01/2021 12:43 PM
> Subject: Re: RENT binder option

[Jim Mulder]

In a separate post, I have said a little
more about rounding and alignment cases for
program objects.

As to the Astonishment in POLA, I would
suggest that astonishment is relative to the
experience of the beholder, as illustrated here:

SPOCK: Captain, the Intrepid would have done all these things too, and yet
they were destroyed.
KIRK: Well, they may not have done all of these things. You just pointed
out how illogical this situation is.
SPOCK: True. It is also true they never knew what was killing them. Their
logic would not have permitted them to believe they were being killed.
KIRK: Explain.
SPOCK: Vulcan has not been conquered within its collective memory. The
memory goes back so far that no Vulcan can conceive of a conqueror. I knew
the ship was lost because I sensed it.
KIRK: What was it you sensed?
SPOCK: The touch of death.
KIRK: And what do you think they felt?
SPOCK: Astonishment.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY

"IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU> wrote on

09/01/2021 09:39:18 AM:

> From: "Paul Gilmartin" <0000000433f0781...@LISTSERV.UA.EDU>
> To: IBM-...@LISTSERV.UA.EDU
> Date: 09/01/2021 01:17 PM
> Subject: Re: RENT binder option
> Sent by: "IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU>
>

[Paul Gilmartin]

On Wed, 1 Sep 2021 13:25:03 -0400, Jim Mulder wrote:
> ...

> As to the Astonishment in POLA, I would
>suggest that astonishment is relative to the

>experience of the beholder, ...
>
The oldest memories are the sharpest. I remember vividly my
astonishment as an MVS/370 novice when I discovered that
RER programs were not protected against modifying themselves
despite ready availability of hardware facilities. (Then I could
grasp the PoOps; no longer.)

I was even further astonished to learn that a program need to
be Authorized in order to not modify itself.

I imagine a program incorrectly marked REFR which depends
on self-modification. It works for years until by happenstance
it is refreshed and fails. Of course: "User Error. WAD."

--gil

[Jim Mulder]

You are further illustrating my point. Your
astonishment was due to your inexperience.

The use of REFR for storage error recovery was only
in predecessors of MVS, and that was before my time
at IBM. I only know about that because of Shmuel's
posts about it.

Although it was before my time, I would guess that the
key 0 protection for RENT programs from APF authorized
libraries was added only because it was required for
system integrity, and limited to APF authorized libraries in
order to avoid migration impediments that would have
resulted from breakage to existing self-modifying RENT
programs in non-APF authorized libraries. That would
have been consistent with MVS's emphasis on compatibility,
and thus is not astonishing to me.

Your "by happenstance it is refreshed and fails" scenario is
unlikely to ever occur, since refreshing is currently done
only for LPA modules, which are DAT-protected. z/OS will
not be implementing refreshing for storage machine checks.
The probability of a storage machine check on current machines
is so low that, if anything, we would be simplifying or removing
storage error machine check processing in z/OS, not enhancing it.
In fact, while doing some work on System Trace in z/OS 2.5, I
discovered that exploitation of 1MB frames for trace buffers in
z/OS 1.10 had introduced a bug where a storage error
machine check recovery for trace structures could result in
an infinite loop. Based on discussion with hardware engineers
about the projections for storage machine checks on the machines
supported by z/OS 2.5, I remediated that by simplifying the
recovery to just discard and rebuild the whole trace structure
for a processor instead of trying to fix the old logic for
removing a single 4K frame from the processor's trace
structure.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY


"IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU> wrote on

09/01/2021 01:58:03 PM:

> From: "Paul Gilmartin" <0000000433f0781...@LISTSERV.UA.EDU>
> To: IBM-...@LISTSERV.UA.EDU
> Date: 09/01/2021 02:40 PM
> Subject: Re: RENT binder option
> Sent by: "IBM Mainframe Discussion List" <IBM-...@LISTSERV.UA.EDU>
>

[Bernd Oppolzer]

Many thanks for that ... I know of very large installations which
depend heavily on being able to modify RENT programs, and loading them
always into write protected storage would break their systems.

In fact, I am talking of a very large customer of mine.
What they do: they load the EP point of called modules only at first call
and store the EP in the caller's static area. The logic how this can be
done
has IMO been posted earlier in this thread (comparing the stored address
with zero, LOAD, if zero and use it, if non zero).

My customer makes sure during development and testing that no other
modification of the load module occurs, apart from this "allowed"
reentrancy violation, as he calls it.

The method described above is used with PL/1, ASSEMBLER and C modules,
and it is done this way in Batch and under IMS/DC control (and even TSO).
These are all load modules, no program objects (no need for program
objects,
because the RENT compile option is not used ... the programs are all
naturally reentrant ... and C++ is not used, that is, forbidden).

BTW: many years ago I suggested to get rid of this method (to store the EPA
in the caller's static CSECT), because this way, two different callers
of the same
module would anyway do two LOADs. I suggested a load manager instead,
which stores the names and addresses of the modules (there are hundreds of
them in an IMS or batch regions) in a self-balancing tree (AVL-tree);
but management did not allow me to do that ... although the migration
would have beed very easy, because all calls go through site-specific macros
anyway, so only those macros would need a change. But ...

The old solution still works.

Kind regards

Bernd



Am 01.09.2021 um 21:18 schrieb Jim Mulder:
> ... and limited to APF authorized libraries in

> order to avoid migration impediments that would have
> resulted from breakage to existing self-modifying RENT
> programs in non-APF authorized libraries. That would
> have been consistent with MVS's emphasis on compatibility,
> and thus is not astonishing to me.
>
>
>

[Seymour J Metz]

The SP252 processing only depends on the concatenatation being APF, not on the J/S being authorized.

I can imagine all sorts of scenarios where an incorrect attribute is not noticed for years, then causes an outage. That;s one of the reasons for code and design reviews.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [0000000433f0781...@LISTSERV.UA.EDU]
Sent: Wednesday, September 1, 2021 1:58 PM
To: IBM-...@LISTSERV.UA.EDU

Subject: Re: RENT binder option

[Paul Gilmartin]

On Wed, 1 Sep 2021 21:53:35 +0200, Bernd Oppolzer wrote:

>Many thanks for that ... I know of very large installations which
>depend heavily on being able to modify RENT programs, and loading them
>always into write protected storage would break their systems.
>

I recognize that the Subject: says RENT and I was among those who
added REFR to the thread. Can we all now agree not to advocate
write-protecting objects that are merely RENT? I will continue to
argue for write-protecting REFR objects.

>In fact, I am talking of a very large customer of mine.
>What they do: they load the EP point of called modules only at first call
>and store the EP in the caller's static area. The logic how this can be
>done has IMO been posted earlier in this thread (comparing the stored address
>with zero, LOAD, if zero and use it, if non zero).
>
>My customer makes sure during development and testing that no other
>modification of the load module occurs, apart from this "allowed"
>reentrancy violation, as he calls it.
>

This is not a violation of IBM's (idiosyncratic?) use of re-entrant (RENT).

>BTW: many years ago I suggested to get rid of this method (to store the EPA
>in the caller's static CSECT), because this way, two different callers
>of the same module would anyway do two LOADs. I suggested a load manager instead,

> ...
Or set a flag in that static area (serialize if necessary) and bypass initialization if set.

Remember and rerspect the distinction IBM makes between RENT and REFR.

-- gil

[CM Poncelet]

(a) I could not possibly 'bet', as I never gamble.
(b) I would not expect e.g. IEFBR14 to be page-aligned (regardless of
its being in the LPA.)
(c) I would expect there to be 'constraints' on what-sized LMODs are
page-aligned, as in "not if less than 1K or 2K or than 4K" or whatever else.
(d) I was referring to LMODs containing 100's of MODs - and occupying
far more than 4K of LMOD storage.
(e) I have had no direct access to a mainframe for the past 8 years
(retired) - hence all this is from memory. 
(d) How about IBM granting me free access to its mainframes - IP
address, userid and password - just so that I can check what I say
before I say it? TIA
 
Attached TPNSX1VT.txt is the only Netview Clist I ever wrote in my life
- and it was written for IBM.
 
Chris Poncelet CEng MBCS CITP
IBM Mainframe Systems Programming Consultant (retired)

> .

[Paul Gilmartin]

On Thu, 2 Sep 2021 02:41:09 +0100, CM Poncelet <ponc...@BCS.ORG.UK> wrote:

>(a) I could not possibly 'bet', as I never gamble.
>

Neither does Peter.

>On 01/09/2021 13:45, Peter Relson wrote:
>> CM Poncelet wrote
>> <snip>
>> The LP (load point) addresses of LMODs always end with x'000' (i.e. page-aligned)
>> </snip>
>>
>> wanna bet?

-- gil

[Peter Relson]

CM Poncelet wrote:
<snip>

I was referring to LMODs containing 100's of MODs - and occupying
far more than 4K of LMOD storage.

</snip>

I suspect that DIAGxx's VSM USEZOSV1R9RULES(YES | NO) might come into play
with respect to whether or not a loadmod (whether 1 csect or 100's) lands
page-aligned. The getmain done by the system for the storage to hold the
loadmod requests page alignment only when that is an attribute of the
loadmod as identified within the directory entry.

Peter Relson
z/OS Core Technology Design