Earlier statements in this thread? No. Earlier statements in other threads? Many times.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 לְשָׁנָה טוֹבָה תִכָּתֵבוּ וְתֵּחָתֵמוּ ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of David Spiegel [[email protected]] Sent: Monday, September 6, 2021 11:33 AM To: [email protected] Subject: Re: RENT binder option Hi R'Shmuel AMV"SH, Don't you agree that your earlier statement has been refuted? Please see: פרקי אבות 5:9 שׁוֹאֵל כְּעִנְיָן וּמֵשִׁיב כַּהֲלָכָה Regards, David On 2021-09-06 11:19, Seymour J Metz wrote: > 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 > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3&data=04%7C01%7C%7Cbb061cfc01ee4f1b0d8508d97149cfef%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637665384157520184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7iVN0eFx0pCBOfyM7InLeG9PxyCy9E4c9yNjIhtCy6c%3D&reserved=0 > > ________________________________________ > 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%7Cbb061cfc01ee4f1b0d8508d97149cfef%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637665384157520184%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7iVN0eFx0pCBOfyM7InLeG9PxyCy9E4c9yNjIhtCy6c%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 > . ---------------------------------------------------------------------- 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
