All of PLPA is by definition refreshable. It implements exactly what refreshable means -- the storage might be "refreshed" (from its original state) at any point the system deems it appropriate to do so.
If a page backing a PLPA is stolen, it is not at that point written to aux storage; writing of all LPA to aux was done during IPL (or a previous IPL possibly). When that page is needed, it is gotten from that previously-captured aux storage. This is the only part of the operating system that performs something akin to "refresh" for modules. You might view some control block refresh from a page-protected copy as refresh of data areas. Beyond that, to z/OS, refresh has meaning only to DIAGxx processing where you can ask, for testing purposes, that refreshable modules be page-protected. You cannot write into a refreshable module and get lasting results (as it might be refreshed at any time), so this is intended to stop even key 0 from incorrectly writing into it. Yes, I know that an authorized program can accomplish writing into the module by undoing the page protection, or by using stores using real address. So the question about refreshable modules is kind of moot. Or I am not understanding the intent. You can share modules by having them in common storage. RLDs are resolved at fetch time. End of story. >Is there a service that will tell a priori the storage requirement of a >load module, or must the programmer simply overrequest; LOAD, and >free the excess? BLDL or DESERV, to access the directory entry, as Binyamin wrote. Within there is the information about the length. You use that information to obtain the storage. You then do a LOAD with ADDR and DE. >Is there any prospect of above-the-bar LPA? 1.13 allows execution above- >the-bar (with severe restrictions), and there should be no obstacle to >keeping data above-the-bar beyond mere 64-bit savvy of the users. There is always a "prospect", but there is no current "likelihood". The "obstacle" is the cost to resolve the "severe restrictions" you rightly mention. It doesn't do any good to put code above the bar that wants to run but cannot meet the "severe restrictions". It is already supported (z/OS 1.11) to do a LOAD with ADDR64 to an area above the bar for non-executable code if you have a data table module that you know can be above the bar (it better not have any 4-byte relocatable adcon's). Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
