On Sat, 10 Jun 2017 16:41:16 -0700, Charles Mills wrote: >A refreshable program may modify itself, right? REFR does not say "I don't >modify myself" it says "you can reload me if you want." Almost the same thing, >but not quite. > Point taken. But it's not clear why the designers chose to allow a program to be both modifyable and reloadable. This leads to dreadful unpredictability: Behavior may differ depending on whether the program has been reloaded. OK. Initialization code may set a flag (in each page?) that will be cleared by a reload. Critical code paths may check (before and after) that the flag remains set and re-initialize if it's found cleared. And the documentation should conscientiously mention the need to do this. Ugh!
>Granted, modifying program storage is a bad idea -- in any event. > Yes. Conceivably, a program could be REFR but not RENT. z/OS components no longer support this. >-----Original Message----- >From: Of Paul Gilmartin >Sent: Saturday, June 10, 2017 7:54 AM > >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
