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 <ponce...@bcs.org.uk> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
