I got tired of guessing. I wrote a little program that saves registers into 
itself via STM. I linked it with AC(1) and RENT. Did not specify either REUS or 
REFR. The result according to StarTool is 

--  ATTRIBUTES   - APF 
RENT REUS           AC

As suggested in the KC doc, REUS is set automatically as a subordinate of RENT, 
but REFR is not set. Result at execution:

If the module is executed from my personal non-APF library, it runs fine.

If the module is executed from an APF library, it get S0C4. 

I was dubious about 'RENT OK if execution is serialized'. This is a single 
execution in batch. No competition. It abends. I don't see how it could be 
otherwise. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Clark Morris
Sent: Sunday, June 11, 2017 5:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: APF authorization and AC(00)

[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

Reply via email to