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 [[email protected]] on behalf of CM Poncelet [[email protected]] Sent: Monday, August 16, 2021 6:22 PM To: [email protected] Subject: Re: RENT binder option 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 On 15/08/2021 23:47, 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 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 <[email protected]> wrote: > >> BTW (off topic) REFR, not RENT, if a module's storage may *never* be >> modified in any way. >> >> > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > . > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
