RENT means only one copy of a module needs to be loaded for a job. REFR means the module doesn't need to be paged out.
All else is implications and assumptions. Note that neither of the above strictly require a non-modifiable module. The idea is that the results are always the same regardless of simultaneous execution, or refreshing, respectively. Both the key-0 protection and the REFRPROT facility *assume* those attributes imply non-modifiability. Sure, they usually do, but why they didn't just create a new "NMOD" (say) attribute and squelch the confusion? And the scientific definition of reentrancy can be (fairly easily) violated by by a program that never modifies itself. All it takes is naive or careless use of a common resource. sas On Sun, Jun 11, 2017 at 3:40 PM, Paul Gilmartin < [email protected]> wrote: > On Sun, 11 Jun 2017 14:13:17 -0400, Peter Relson wrote: > > >A refreshable program cannot modify itself (or if it can, it would be a > >very interesting and perhaps self-limiting testcase). > > > I believe that if a program is marked REFR but loaded from a > non-authorized library and REFRPROT is not in effect, no error > is reported at that time. Behavior is unpredictable when > a refresh may actually occur. > > >... A reentrant program > >can, if written carefully, modify itself, although it is rarely a good > idea. > >LPA modules are generally, in effect, refreshable. > > > Does this mean that REFRPROT "in effect" applies to LPA modules? > > >As to "why", think about it. > >Page protection did not even exist at the time RENT and REFR were defined. > >And over those 20-30 years, many many programs were incorrectly bound with > >"RENT,REFR" when in fact they were RENT but not REFR. But they worked fine > >given the way the system processed. > >The combination was used indiscriminately, and often thought of as a pair. > >Making it the default would be horribly incompatible. > > > It's like a child whining about a distasteful medicine: in the > end it's good for him and should be done, even as user key > CSA has been disabled (I think). > > Programmers who didn't RTFM deserve what they get; it's easy > enough to relink with NO REFR. > > >Thus we made it an option and encouraged IBM code and ISV code to fix > >their binder attributes so that REFR could be used in this way, with the > >new processing enabled by use of REFRPROT. > > > Code residing authorized llibraries was strongly "encouraged", > regardless of the REFRPROT setting. I suppose that's true > additionaly for end-user code. > > In the Program Management UG and Ref, I see: > RENT > ... A reenterable module is ordinarily expected not to modify > its own code. In some cases, MVS protects the reentrant module's > virtual storage so that it cannot be modified except by a > program running in key 0. These cases include programs which > the system treats as having been loaded from an authorized > library, ... > > Is that right? It seems to be describing REFR, not RENT. And > the "treats as" waffling? Is that referring to LPA, regardless of > load module attributes? And "include" hints at other cases, not > mentioned. > > >And, yes, it is a performance consideration. Not a huge one, but one > >nevertheless. > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- sas ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
