[Default] On 11 Jun 2017 13:39:47 -0700, in bit.listserv.ibm-main 0000000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) 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. Unfortunately at this late date, it probably will be a mission critical program last modified ten years ago by someone who has left the organization. The program or module in question may be even older. Also it may be from an ISV that distributes object code only. The using organization can be in a world of hurt. Is there a bit available that could be used to denote REFRPROT ready? Clark Morris > >>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 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
