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
