If REFRPROT is not specified then a refreshable module can modify itself. Don't do it at home.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM Poncelet [ponce...@bcs.org.uk] Sent: Sunday, February 7, 2021 5:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL Of course. I have never suggested that it was *reasonable* to ENQ/DEQ or otherwise serialize code in a RENT module, but only that it was *possible* to do so without compromising an LMOD's RENT attribute. Likewise, when I said a REFR LMOD could be "swapped out", I meant its page(s) could be "stolen" by the O/S at any time without its having first to "back up" the LMOD to a paging dataset or cache. Michael Stein provided an excellent summary of the meanings of REUS, RENT and REFR in his "load module search order and attributes" post. I recommended that ASM modules should always be coded as RSECTs (not as CSECTs) to allow the assembler to trap, whenever possible, any code that could modify itself. AFAIR Any LMOD marked "RF" (REFR) will abend S0C4-4 if it modifies itself during execution. Chris Poncelet (retired sysprog) On 07/02/2021 16:52, Seymour J Metz wrote: > It's a bit more complicated. First, you can decouple REFR from RENT by using > the linkage editor. Second, you can write code that is reentrant and > refreshable, modifies itself and does not use ENQ/DEQ. However, I suspect > that at some point REFRPR"OT will be mandatory. > > BTW, just because it is possible doesn't mean that it is a reasonable thing > to do; absent compelling reasons otherwise, I would red flag it in a code > review. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > CM Poncelet [ponce...@bcs.org.uk] > Sent: Friday, February 5, 2021 9:57 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LINK vs LOAD/CALL > > No. RENT implies REUS. Meanwhile RENT *may* be modified IFF an ENQ is > first issued on the code to be modified, provided that code is then > restored to what it was before it was ENQ'd and then DEQ'd. Only REFR > prohibits any code modification (because REFR means that an LMOD can be > swapped out and refreshed from its original copy on DASD, at any time > during execution and without interruption) - and REFR implies RENT > implies REUS, but RENT does not imply REFR. > > > > On 05/02/2021 20:02, Joseph Reichman wrote: >> Sorry to jump in here but can you have rent without reus >> >> >> >>> On Feb 5, 2021, at 2:59 PM, Seymour J Metz <sme...@gmu.edu> wrote: >>> >>> If the module is not REUS then every LOAD will get a different copy. If >>> the module is REUS but not RENT then LOAD, ENQ, CALL, DEQ, DELETE is safe. >>> Using LOAD, SYNCH, DELETE is left as an excise for the reader. In most >>> cases I would use LINK(X). >>> >>> >>> -- >>> Shmuel (Seymour J.) Metz >>> http://mason.gmu.edu/~smetz3 >>> >>> ________________________________________ >>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >>> Bernd Oppolzer [bernd.oppol...@t-online.de] >>> Sent: Friday, February 5, 2021 1:41 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: LINK vs LOAD/CALL >>> >>> I would like to add: >>> >>> while LINK is functionally the same as LOAD - CALL - DELETE, >>> there is an important difference: >>> >>> the transfer of control with LINK is known to the operating system, >>> but with LOAD - CALL - DELETE, it is NOT known. >>> In fact, CALL is not a supervisor action, it is simple machine >>> instructions (very cheap). >>> This means that if a module is not RENT and not REUS (for example), >>> a call using LOAD - CALL - DELETE is not safe, because the system does >>> not know that >>> the module is in use. Another subtask can easily call the same module at >>> the same time, >>> if it knows the address, and it will never get another copy. You are >>> responsible yourself >>> for doing things right. >>> >>> With LINK, on the contrary, if the module is not RENT and not REUS, the >>> system >>> will ALWAYS fetch a new copy, when you do another LINK. >>> >>> (There is a "use count" in the control blocks, which is incremented and >>> decremented >>> during LINK processing, but of course not, when doing a CALL). >>> >>> Kind regards >>> >>> Bernd >>> >>> >>>> Am 05.02.2021 um 18:54 schrieb Frank Swarbrick: >>>> I am not a systems programmer. I am a COBOL programmer who knows only >>>> enough assembler to be dangerous. >>>> What is the "difference" between doing a LOAD and a CALL to perform a >>>> dynamic call and doing a LINK? >>>> >>>> ---------------------------------------------------------------------- >>>> 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 >> ---------------------------------------------------------------------- >> 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 ---------------------------------------------------------------------- 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
