Regarding page-protecting only the "whole pages", there really are only two viable choices. One is to do what we do; the other is to round up the module to a whole-page multiple. The latter can conceivably break applications.
Other options that you might submit an RFE for, but that are not "safe" if you have code that is nominally reentrant but does (let's hope correctly) store into itself are: -- always put reentrant code into key 0 storage, regardless of APF state (this does happen for a KEY=NINE task) -- always page-protect reentrant code either of these will break non-key-0 reentrant code that stores into itself. <snip> I wonder if anything in zOS considers that a non-LPA page of a REFR module need not be backed to paging, because if it is needed to be refreshed, can the operating system really count on being able to reload the page from the original load library? </snip> The operating system cannot count on being able to reload from the original load library. Yes it's true that if the module were paged out it would not need to be paged out again. I suspect that remembering that would be extremely problematic (in terms of the space needed to track such situations). <snip> In other words, does REFR mean anything to the OS other than the possibility of loading the module into page protected storage? </snip> No it doesn't, and prior to REFRPROT I think that it meant nothing. <snip> If it were up to me REFRPROT would be the default, but IBM has better data than I do and doesn't agree. </snip> That would be incompatible. So unless there was data to prove that nothing would break (and that no one would care about the extra cycles of page-protecting). I cannot imagine ever changing to make REFRPROT be the default. A disturbing number of posts seem to ignore the fact that a significant part of the reason that we still have a z/OS operating system is because of the impressive amount of long-term compatibility that it provides. And, yes, that does put burden on new things to deal with decisions made long ago that we dare not change. We do live with the "sins" of our past design decisions. Yes, of course, we do make incompatible changes when deemed appropriate. <snip> The last I looked, MVS does not write back a modified PLPA page before stealing it. I don't know how difficult it would be to do the same for full page RENT code. </snip> MVS does not ever page out a PLPA page aside from what it does during IPL. This only works because the bounds of LPA are unchangeable within an IPL and the storage can be mapped to the page data set that contains the initial PLPA pages. If you modify a PLPA page you'd better make sure it's page-fixed. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
