I was very surprised by Chris Poncelet's post, so I used Goggle to find this doc:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab100/iea3b1_Module_reusability.htm Blew me away. I knew the definition of RENT and REFR, but I believed that both attributes were set in combination if either one was specified. So what is the difference *in practice* between RENT and REUS? Both seem to imply that a module can be executed successively by multiple callers. Furthermore, in practice, who in the world would bother with ENQ/DEQ rigmarole to serialize execution of a RENT module instead of just coding it REFR in the first place? REFR is not that difficult if you set out to do it from the get-go. And last, what would happen if a self-modifying RENT module were in fact executed concurrently by multiple callers without ENQ/DEQ? Incorrect result? Abend? I'm verklempt. . . 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 CM Poncelet Sent: Saturday, June 10, 2017 7:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: APF authorization and AC(00) Not AFAIK. In theory, a RENT program may modify one of its sections provided that this section is preceded by an ENQ, then modified, then restored to its original value and then DEQ'd - to ensure that only one user can execute the modifying section of code at any one time. It is a REFR program that may never modify itself in any way. (The "RENT" just means it can be executed concurrently by multiple users - although some might have to wait for a DEQ. The "REFR" means it can be reloaded exactly asis from DASD at any time whilst it is still being executed, e.g. back into the PLPA after a page-steal by the RSM.) Chris Poncelet (retired sysprog) On 11/06/2017 00:41, 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. > > Granted, modifying program storage is a bad idea -- in any event. > > Charles > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Paul Gilmartin > Sent: Saturday, June 10, 2017 7:54 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: APF authorization and AC(00) > > 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? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
