There is no requirement that a self modifying reentrant module ever restore its original contents. The sole requirement is that concurrent invocations yield the correct result. it doesn't matter whether serialization is CS, ENQ, latch, lock, TS or "E. None of the above."
Likewise for RENT: the sole requirement is that it produce the correct result even if refreshed in meias res. Now, for both REFR and REFR there are contexts where IBM imposses additional constraints, e.g., authorized concatenations, PLPA, REFRPROT. And just because it is permissible for REFR and RENT code to modify itself doesn't mean that yoush should write self modifying code for production. IMHO such could should only be written as classroom exercises. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of CM Poncelet [[email protected]] Sent: Friday, September 3, 2021 10:05 PM To: [email protected] Subject: Re: RENT binder option At the risk of inviting 'flak', I suspect that there is a misconception of what RENT and REFR modules actually are. By definition, RENT and REFR modules should never modify themselves (excluding the peculiar case of a RENT module that ENQ's on part of its code, modifies it, restores it to what it was, then DEQ's it - as this would not violate the definition of RENT modules being concurrently executable by multiple tasks.) A module is REFR or RENT - not if it is link-edited as REFR or RENT, but if it never modifies its own storage. In other words, all modifiable storage must first be GETMAINed (including the module's savearea storage) and any WTO(R)s and DYNALLOC/SVC-99s, DCBs, ACBs and/or RPLs etc. must then use the 'list' and 'executable' forms of these macros/DSECTs to avoid modifying the module's own storage.) As a 'first line of defence', such modules should be coded as RSECTs and not as CSECTs - and the assembler will then trap (with a CC=08, IIRC) any direct attempt to modify the module's own storage. But it is the programmer/developer who is responsible for ensuring that the module's code is indeed REFR or RENT - and it is not the linkage-editor or binder's responsibility. Arguing that REFR or RENT modules need to be 'protected' from modifying themselves, or by others, is methinks beside the point - because such modules should have been coded in such way that they *never* modify themselves to begin with. If others can modify them, then it is these other modules that should be investigated, not the REFR or RENT ones. On 03/09/2021 13:34, Paul Gilmartin wrote: > On Thu, 2 Sep 2021 16:02:07 -0400, Jim Mulder wrote: > >> I found IBM RENT modules that modified themselves >> 15 years ago when I was experimenting to see what would >> happen if we tried to page-protect RENT modules. I have a list: >> > Have you a similar list of IBM REFR modules that modify themselfes? > > Does the setting of REFRPROT affect processing of modules > marked RENT but not REFR? > > What were the reusability attributes of the module in OA25089? > >> ANTMAIN >> ANTSDMLK >> IEAVNIPX >> EZATNF >> IOEFSKN >> FNMVZJV >> FNMVZCVA >> EZAXVMCF >> DSNHDECP >> DSN9PARM >> DSN3INI >> CNMINIT >> CNMCSSIM >> CNMCSSIC >> >> We subsequently removed the unintended RENT from IEAVNIPX. >> So we don't page-protect RENT modules (except for experimental >> purposes under control of another undocumented DIAGxx TRAP name), >> and we implemented REFRPROT instead. I haven't heard about >> any IBM modules that get broken by REFRPROT. > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > . > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
