IIRC The page(s) of an LMOD marked REFR can be stolen without having first to back it up to cache, because it can be REFReshed from cache (or DASD) and continue to execute as if its page(s) had not been stolen - e.g. in the PLPA. If it modified itself, it would hit a S0C4-4. AFAIK A backup/swap-out would be needed if it was marked RENT but not REFR.
On 25/08/2021 22:41, Paul Gilmartin wrote: > On Wed, 25 Aug 2021 15:56:33 -0500, Barry Lichtenstein wrote: > >> ... (NORENT and REFR). The binder treats reusability as a hierarchy, REFR >> implies RENT, ... > They saved a bit by allowing the reusability to have 4 values instead of 8. > (NORENT and REFR) could have made sense if a programmer had > relied on them to serialize access to shared data areas. Well, no. CSV > would simply load another instance. > > >> On Sun, 15 Aug 2021 18:47:26 -0400 Steve Smith wrote: >>> Seems like deja vu. For all practical purposes, RENT and REFR (which >>> implies RENT) have the same effect (that may be a tautology). >>> >>> For whatever reasons, RENT & REFR ... or for the ability to >>> tolerate a refresh. Neither of those things absolutely requires >>> non-modification, so one wonders why IBM wandered off into those tangents. >>> > I'm trying to envision what is needed for modified code to tolerate a > refresh. Field the protection exception; proceed with the refresh; > and re-drive the failed operation ab ovo? I suppose. > > -- gil > > ---------------------------------------------------------------------- > 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
