Re: RENT binder option
"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 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 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
Re: RENT binder option
Exactly. On 05/09/2021 00:55, Andrew Rowley wrote: > On 5/09/2021 7:51 am, CM Poncelet wrote: >> AFAIK The difference between RENT and REFR is that REFR pages (or >> frames) can be stolen without their having first to backed up - because >> they can be REFReshed from cache or DASD without this affecting the >> code's execution - whereas RENT code pages do need to be backed up >> before they can be stolen. > Right. And why do they need to be backed up? Because they might be > modified. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 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
Re: RENT binder option
On 5/09/2021 7:51 am, CM Poncelet wrote: AFAIK The difference between RENT and REFR is that REFR pages (or frames) can be stolen without their having first to backed up - because they can be REFReshed from cache or DASD without this affecting the code's execution - whereas RENT code pages do need to be backed up before they can be stolen. Right. And why do they need to be backed up? Because they might be modified. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HLAM and RENT binder option
Well, the assembler cannot truly report on RENT vs REFR violations, as that can only be determines by running the code. The assembler has no idea if a lock is serializing a section of code. On Sat, 4 Sep 2021 13:11:39 -0600 Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: :>(Cross-posting to IBM-MAIN and ASSEMBLER-LIST) :>It's a shame that HLASM (AFAIK) conflates IBM's venerable use of :>RENT and REFR. :>This has led to misunderstanding in this long IBM-MAIN thread. :>And recurrent false reporting by HLASM of RENT violations in :>code that is RENT-compliant but merely violates REFR. :>I suppose it's too late to fix it. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
AFAIK The difference between RENT and REFR is that REFR pages (or frames) can be stolen without their having first to backed up - because they can be REFReshed from cache or DASD without this affecting the code's execution - whereas RENT code pages do need to be backed up before they can be stolen. On 04/09/2021 09:34, Andrew Rowley wrote: > On 4/09/2021 12:05 pm, CM Poncelet wrote: >> 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. > If a RENT module is not allowed to modify it's own storage, what is > the difference between RENT and REFR? > > A RENT module can modify its own storage, it just needs to be done in > a way that is synchronized correctly between multiple tasks. As a > contrived example, imagine you had a module that counted how many > times it was invoked. You could keep that counter in program storage, > as long as the updates were appropriately synchronized. It doesn't > actually matter whether the counter is in GETMAINed storage or in the > module itself - either way updates need to be synchronized. > > I wouldn't be surprised if a modifiable field in a RENT module is one > of the best performing ways to keep a reference to shared state > information. Conceptually it is the same as static fields in e.g. a > C++ or Java class - the value is shared by every running instance, > while information that is specific to an instance is kept in GETMAINed > storage. > > I ran into this many years ago when I "cleaned up" and removed an > empty library from the STEPLIB of one of our subsystems. That suddenly > meant that the STEPLIB was considered APF authorized, which resulted > in S0C4 abends when the subsystem was started and it tried to store > information in its RENT load module. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
HLAM and RENT binder option
(Cross-posting to IBM-MAIN and ASSEMBLER-LIST) It's a shame that HLASM (AFAIK) conflates IBM's venerable use of RENT and REFR. This has led to misunderstanding in this long IBM-MAIN thread. And recurrent false reporting by HLASM of RENT violations in code that is RENT-compliant but merely violates REFR. I suppose it's too late to fix it. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
Like. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: 04 September 2021 18:43 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RENT binder option It's really a shame that IBM-MAIN does not have a "Like" button. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Friday, September 3, 2021 11:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RENT binder option Long ago, when I was a new hire at IBM, fresh out of college with my hoity toity computer science degrees, and without enough experience to have much real work to do, I would try to argue with the MVS developers about how MVS perverted the definitions of computer science terms, like using "queue" to refer to any linked list, when "queue" was supposed to be an abstract ordered data structure with specific addition and deletion protocols. And they would mostly tolerantly ignore me and tell me that before long, I would be just like them with too much work to do and no time to argue about such things. And I thought, "No way! They are wrong. I will always make time to be passionate about that." But it didn't take long for them to be proved correct. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
It's really a shame that IBM-MAIN does not have a "Like" button. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Friday, September 3, 2021 11:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RENT binder option Long ago, when I was a new hire at IBM, fresh out of college with my hoity toity computer science degrees, and without enough experience to have much real work to do, I would try to argue with the MVS developers about how MVS perverted the definitions of computer science terms, like using "queue" to refer to any linked list, when "queue" was supposed to be an abstract ordered data structure with specific addition and deletion protocols. And they would mostly tolerantly ignore me and tell me that before long, I would be just like them with too much work to do and no time to argue about such things. And I thought, "No way! They are wrong. I will always make time to be passionate about that." But it didn't take long for them to be proved correct. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
On Fri, 3 Sep 2021 19:49:55 -0400, Jim Mulder wrote: >1. No. I would expect any such incidences to be treated as a defect and >fixed. > >2. No > >3. It was REFR and is still REFR. It was just a simple code bug, >passing a field in the static area to BPX1OPT for a >return parameter that gets modified by BPX1OPT. > Thanks for your detailed answers to many questions in this by now tedious thread. >"IBM Mainframe Discussion List" wrote on >09/03/2021 08:34:33 AM: >> From: "Paul Gilmartin" >> To: IBM-MAIN@LISTSERV.UA.EDU >> >> 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? Thanks again, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Shopz order eliminate superseded service
On Sat, 4 Sep 2021 08:09:39 -0500, Bill Giannelli wrote: >When I order maintenance from Shopz there is the option to eliminate >superseded service. should this be normally selected? > Perhaps not, against the eventuality that the SUPerseding SYSMOD go HOLD ERROR and the SUPerseded SYSMOD remain valuable. Similarly, I argued, successfully, that our process should allow the SYSMOD that resolves a PE HOLD to PREreq, not only SUPersede the PE PTF for the case where the earlier PDF contained numerous elements and the PE could be corrected by replacing only one of them. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
When they were young I told my artist daughters that there's Art, and then there's the Art Business. They are quite different. On 9/3/2021 11:59 PM, Jim Mulder wrote: Long ago, when I was a new hire at IBM, fresh out of college with my hoity toity computer science degrees, and without enough experience to have much real work to do, I would try to argue with the MVS developers about how MVS perverted the definitions of computer science terms, like using "queue" to refer to any linked list, when "queue" was supposed to be an abstract ordered data structure with specific addition and deletion protocols. And they would mostly tolerantly ignore me and tell me that before long, I would be just like them with too much work to do and no time to argue about such things. And I thought, "No way! They are wrong. I will always make time to be passionate about that." But it didn't take long for them to be proved correct. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Shopz order eliminate superseded service
IMHO, yes. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Saturday, September 4th, 2021 at 9:09 AM, Bill Giannelli wrote: > When I order maintenance from Shopz there is the option to eliminate > superseded service. should this be normally selected? > > thanks > > Bill > > - > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF field data
It appears that these 2 fields, ENDUSERWN and ENDUSERWN_L in BMC (QWHCEUWN and QWHCEUWN_Var in SMF) are blank for all records from 2 of our LPARS for all DB2 members on those LPARS. The fields are populated from a third LPAR for all DB2 members on that LPAR. I have not found any differences in the DB2 traces. Is there something LPAR specific that would restrict this data? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Shopz order eliminate superseded service
When I order maintenance from Shopz there is the option to eliminate superseded service. should this be normally selected? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
"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 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > . > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
On 4/09/2021 12:05 pm, CM Poncelet wrote: 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. If a RENT module is not allowed to modify it's own storage, what is the difference between RENT and REFR? A RENT module can modify its own storage, it just needs to be done in a way that is synchronized correctly between multiple tasks. As a contrived example, imagine you had a module that counted how many times it was invoked. You could keep that counter in program storage, as long as the updates were appropriately synchronized. It doesn't actually matter whether the counter is in GETMAINed storage or in the module itself - either way updates need to be synchronized. I wouldn't be surprised if a modifiable field in a RENT module is one of the best performing ways to keep a reference to shared state information. Conceptually it is the same as static fields in e.g. a C++ or Java class - the value is shared by every running instance, while information that is specific to an instance is kept in GETMAINed storage. I ran into this many years ago when I "cleaned up" and removed an empty library from the STEPLIB of one of our subsystems. That suddenly meant that the STEPLIB was considered APF authorized, which resulted in S0C4 abends when the subsystem was started and it tried to store information in its RENT load module. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
Long ago, when I was a new hire at IBM, fresh out of college with my hoity toity computer science degrees, and without enough experience to have much real work to do, I would try to argue with the MVS developers about how MVS perverted the definitions of computer science terms, like using "queue" to refer to any linked list, when "queue" was supposed to be an abstract ordered data structure with specific addition and deletion protocols. And they would mostly tolerantly ignore me and tell me that before long, I would be just like them with too much work to do and no time to argue about such things. And I thought, "No way! They are wrong. I will always make time to be passionate about that." But it didn't take long for them to be proved correct. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
With respect to your last paragraph, I am not arguing. I am stating facts. 1. z/OS System Integrity requires that modules which execute in authorized state and are addressable by unauthorized programs must be protected from modification by unauthorized programs, z/OS is designed to satisfy this requirement by using key 0 storage for Nucleus, LPA, and load modules and program objects in APF-authorized libraries that have the RENT attribute. Developers of modules which execute in an authorized state are required to understand this and use these techniques where needed to ensure that their modules conform to this requirement. You are free to have the opinion that using the RENT attribute for this purpose by the MVS designers over 45 years ago was a perversion of the definition of RENT, and that they should not have done that, and possibly used REFR or created a new attribute for that purpose. And I might be inclined to agree with that opinion. I expect that they had pragmatic development cost reasons for doing what they did, and regardless of the reasons, we are stuck with remaining compatible with that, because compatibility is one of the things that keeps z/OS in business, and we like to stay in business. 2. z/OS is not required to protect programs from modification by programs running in an authorized state, However, for system reliability, availability, and serviceability reasons, we find it to be very useful to do so where possible. That is why LPA has been DAT-protected since MVS SP1.3 on enhanced 3033 machines, and why the read-only nucleus has been DAT-protected since MVS/XA, and why I experimented with the possibility of DAT-protecting RENT modules, and ended up implementing REFRPROT. You are free to have the opinion that using the REFR attribute for REFPROT was a perversion of the definition of REFR, and I won't argue against that. We are constrained as always by pragmatic development cost considerations. Such is life in software engineering. Creating a new attribute would be more expensive. and we have space constraints in the PDS directory entry, and getting exploitation by rebinding a lot of things with a new attribute would be expensive, and there were already quite a few things that are bound with the REFR attribute, which provided zero-cost exploitation. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 09/03/2021 10:05:13 PM: > From: "CM Poncelet" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 09/04/2021 01:21 AM > Subject: Re: RENT binder option > Sent by: "IBM Mainframe Discussion List" > > 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
