Golly. Is that so?
On 18/08/2021 09:46, 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? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Discussion List [[email protected]] on behalf of > CM Poncelet [[email protected]] > Sent: Tuesday, August 17, 2021 11:28 PM > To: [email protected] > Subject: Re: RENT binder option > > 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 [[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 >> . >> > ---------------------------------------------------------------------- > 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
