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."
On 17/08/2021 22:31, Seymour J Metz wrote: > 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-MAIN@LISTSERV.UA.EDU] on behalf of > CM Poncelet [ponce...@bcs.org.uk] > Sent: Monday, August 16, 2021 6:22 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 <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 > > ---------------------------------------------------------------------- > 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
