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 [[email protected]] on behalf of CM Poncelet [[email protected]] Sent: Friday, February 5, 2021 9:57 PM To: [email protected] 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 <[email protected]> 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 [[email protected]] on behalf of >> Bernd Oppolzer [[email protected]] >> Sent: Friday, February 5, 2021 1:41 PM >> To: [email protected] >> 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 [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
