Yes, BTDT,GTTS. IMHO, installing PDS86, StarTool oe whatever the current name is, is a no brainer, and we owe Bruce a debt of gratitude.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of David Spiegel [[email protected]] Sent: Sunday, September 5, 2021 8:49 PM To: [email protected] Subject: Re: RENT binder option Hi R'Shmuel AMV"SH, You said: "... That's why you have to rebuild from the object modules if a reentrant module was incorrectly linked as REUS. ...". If you have the PDS Command Processor (CBT File 182) or Startool, you can "edit" the directory entry to add/remove these and other attributes (e.g. AC(0)/AC(1)). Shana Tovah Regards, David On 2021-09-05 17:44, Seymour J Metz wrote: > There used to be a children's game called telegram, where a group of children > sat in a circle, one got a text and quietly read a short text to an adjacent > chile, who quietly repeated it to the next child, etc., until it came back to > the first child, who compared it to the original text. Those who know wrote > what they aactually wrote, not what was attributed to them. > > BTW, the text that you cited is incorrect;it's not whether the icluded module > actually is refreshable or reentrant that affects the linkage editor, it's > whether it is flagged with the attribute. That's why you have to rebuild from > the object modules if a reentrant module was incorrectly linked as REUS. > > > -- > Shmuel (Seymour J.) Metz > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3&data=04%7C01%7C%7C843fac68f3a241365cd808d970b6669c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637664751026547371%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OKM89FQ1NHIocWcpseIqFif00l3K4gvK1QpKtrha4AQ%3D&reserved=0 > > ________________________________________ > From: IBM Mainframe Discussion List [[email protected]] on behalf of > CM Poncelet [[email protected]] > Sent: Saturday, September 4, 2021 8:06 PM > To: [email protected] > Subject: Re: RENT binder option > > 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 > . ---------------------------------------------------------------------- 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
