"A module is REFR or RENT - not if it is link-edited as REFR or RENT, but if it never modifies its own storage."
Why do you keep lecturing us on things we already know? Jim Mulder knows it best as he is the frickin author of z/OS (well he and Peter Relson). Please stop. "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." To quote the MVS/370 linkage editor user's guide from 1985: "If the reenterable attribute is specified, and any load modules that are not reenterable become a part of the input to the linkage editor, the attribute is negated." "If the refreshable attribute is specified, and any load modules that are not refreshable become a part of the input to the linkage editor, the attribute is negated." So, it has been the case since 1985 that the linkage editor does check the input load modules, and will not mark a non-RENT/REFR load module as having those attributes. Jim Mulder has been at IBM for 42 years, so 1985 ... yeah he would've been working on MVS then. Thanks. Joe On Fri, Sep 3, 2021 at 9:05 PM CM Poncelet <[email protected]> wrote: > 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
