REFR pre-MVS was used by the Machine Check Handler (MCH) to determine whether it was allowed to refresh code after an uncorrectable memory failure. That recovery code does not exist in z/OS. RFER and RENT were independt options; a module could be both, one or neither.
RENT controlled serialization. Loading into SP252 key 0 was an RAS issue rather than required behavior. There is and never has been frefreshing of main memory from cache, only from DASD. I know of no IBM operating systems that test REFR in order to deternine whether to back up a page. Page-steal from PLPA discards modified pages whether the contains a flagged REFR or not. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of CM Poncelet [[email protected]] Sent: Saturday, September 4, 2021 5:51 PM To: [email protected] Subject: Re: RENT binder option AFAIK The difference between RENT and REFR is that REFR pages (or frames) can be stolen without their having first to backed up - because they can be REFReshed from cache or DASD without this affecting the code's execution - whereas RENT code pages do need to be backed up before they can be stolen. On 04/09/2021 09:34, Andrew Rowley wrote: > 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. > ---------------------------------------------------------------------- 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
