Another question: Wasn't REFR for SVC type 3/4 modules so that they could be refreshed in the transient area following preemption without fear that they may have been modified prior to being preempted?
Sent from my iPhone > On Jun 11, 2017, at 20:52, Steve Thompson <ste...@copper.net> wrote: > >> On 06/11/2017 05:33 PM, Walt Farrell wrote: >>> On Sun, 11 Jun 2017 15:40:49 -0500, Paul Gilmartin <paulgboul...@aim.com> >>> wrote: >>> 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. >> It's descibing RENT, because for programs linked as RENT MVS places the load >> module into key 0 storage if the program was loaded from a library treated >> as APF-authorized. Such programs can modify themselves if running in key 0. >> If they were REFR, and REFRPROT were in effect, they would be in key 0 >> storage and page-protected, and could not modify themselves. > > <snippage> > > Question: Wasn't REFR for a program where, say a double-bit parity error > could occur, and it would then get loaded to a new page? > > Regards, > Steve Thompson > > ---------------------------------------------------------------------- > 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
