>From Michael Stein's excellent summary of REFR:
refreshable:
all or part of the module can be replaced at any time without notice
by the operating system. *therefore* must not modify itself in
any way.
Never heard of REFRPROT or how it differs from REFR. Perhaps it's after I
retired (7+ years ago) <g>
Chris Poncelet (retired sysprog)
On 08/02/2021 02:10, Seymour J Metz wrote:
> 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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
