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
