Wow a seal team 6 member ... On Sat, Jun 10, 2017 at 10:54 AM Paul Gilmartin < 0000000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Sat, 10 Jun 2017 07:27:15 -0400, Peter Relson wrote: > > >>REFRPROT extends this to programs that are not loaded from an > >>APF authorized library. > > > >Actually, REFRPROT extends this to programs that are bound with the REFR > >option regardless of module authorization or library authorization. > >And it goes further because it page-protects, which would cause the > >program to blow up even if were running key 0 if it attempted to store > >into itself. > > > I remain mystified, Why was not the REFRPROT behavior the default > (or only) behavior ever since the inception of the REFR attribute? > o Is there a performance penalty for REFRPROT that developers > wanted to circumvent for problem programs? Contrariwise, it seems > that coding a test for the authorized status of the load library was > needless effort. > o Did the developers assume, very incorrectly IMO, that they were > extending a courtesy to application programmers by permitting > programs that modified themselves to be marked REFR? > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN