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
