"Thanks again for 'absolving' me from having to defend and protect systems programming from being reduced to mere systems administration, then to level-2 and then level-1 tech support, then to help-desk support - as per Micro$oft Windoze. I thoroughly appreciate your supporting mainframe systems programming."
I didnt absolve you from anything. Jim Mulder finely put you in your place. Joe On Sat, Sep 4, 2021 at 7:06 PM CM Poncelet <[email protected]> wrote: > Sure. Thank you for confirming that those who know agree with what I > have said - for the benefit of those who do not know and who might > otherwise be misled into thinking that REFR and RENT LMODs need to be > 'protected' from modifying themselves and/or can modify themselves or > whatever nonsense else. > > BTW Off-topic, my hard-copy "MVS/Extended Architecture Linkage Editor > and Loader Users's Guide" version 2 release 2.0 (order number > GC26-4143-1) second edition (June 1986) agrees with your MVS/370 linkage > editor user's guide from 1985, as quoted. And I would most respectfully > point out that e.g. "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" does indeed apply if any > module's OBJ code has not been link-edited with the REFR attribute but > is then included in the LMOD's link-edit SYSLIN cards, *then* the > resulting LMOD is marked not REFR regardless of all other link-edited > modules included in the said SYSLIN cards having been marked REFR. > > Thanks again for 'absolving' me from having to defend and protect > systems programming from being reduced to mere systems administration, > then to level-2 and then level-1 tech support, then to help-desk support > - as per Micro$oft Windoze. I thoroughly appreciate your supporting > mainframe systems programming. > > I can now gladly drop out of this thread. > > Cheers, Chris Poncelet (retired etc.) > > > On 04/09/2021 11:31, Joe Monk wrote: > > "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 > > . > > > > ---------------------------------------------------------------------- > 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
