It is certainly true that there are cases where a self modifying REFR and RENT module is more efficient, but IMHO that is asking for trouble. It's the sort of think that I would ask a student to do while learning the concepts, but warn against doing in production.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Andrew Rowley [[email protected]] Sent: Saturday, September 4, 2021 4:34 AM To: [email protected] Subject: 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 [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
