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

Reply via email to