It is many years ago since I was involved in IMS, but I seem to remember that IMS used serially reusable modules for its transactions. Maybe that has changed now. I am thinking back to the 1980s.
Lennie Dymoke-Bradshaw https://rsclweb.com 'Dance like no one is watching. Encrypt like everyone is.' -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Seymour J Metz Sent: 12 November 2021 16:23 To: [email protected] Subject: Re: specific purpose for the REUS parameter in a binder operation While it is bad form, a RENT module may modify itself. There are circumstances in which some or all of a RENT modules may be protected, so the devil is in the details. Back in OS/VS2 3.8, the only exception was loading from an APF concatenation, which put it in SP252, key 0. A key 0 task could still modify the code, but if it was in PLPA then page steal would not page out the modified page. There are more special cases these days. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Rupert Reynolds [[email protected]] Sent: Friday, November 12, 2021 9:36 AM To: [email protected] Subject: Re: specific purpose for the REUS parameter in a binder operation Thanks for the reminder of REUS. If I may test my memory here, the difference between REUS and RENT is declaring to system that the program does not modify any local storage at all, (obtaining any storage needed at run time), and if it is loaded from an APF-authorised library it should be loaded into shared write-protected storage. I hope my memory is right. It's been a while, and the last opportunity for this sort of thing was on MVS 3.8 :-) Roops On Fri., Nov. 12, 2021, 13:44 Peter Relson, <[email protected]> wrote: > The specific purpose of the REUS binder option is to tell the system > (that being program fetch) that this module is to be considered > serially reusable. Serially reusable is different than reentrant. > Serially reusable is considerably "weaker" than reentrant. But it is > "stronger" than not reusable and not reentrant. > > I would think it very unusual these days to have any interest in > creating a serially reusable module. > > Given that the system definition of serially reusable is that the > module may be used only once at a time, you land with a "wait queue" > if there are additional requests to use the module while it is > currently in use. So to the question of whether a (serially) reusable > module will be fetched each time, the answer is "no". If the module is > already in storage and there is a waiter, that copy will be used once > it is not being used by something else. > > But your case really sounds like it has nothing to do with any of this. > You don't use a routine to "designate the program as reusable"; you > use the binder to set the directory entry to indicate that the program > is reusable. And reusable is an attribute of the whole load module / > program object, not of a piece within it. So maybe this interface > tells LE to treat the program as reusable whether it is or is not? > > Peter Relson > z/OS Core Technology Design > > > ---------------------------------------------------------------------- > 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
