> Is x'00' better than other mask values? Why? Is TM preferable > to IC or ICM or L or LH or CLC or ...? (What's the fastest way > to clear a register?)
Irrelevant. Only one (fetch) reference per page would be needed to provoke contents supervision into loading and initializing any deferred load classes in a program object. For non-program objects (and program objects without any deferred load classes) there would be no point at all. > Was there any good rationale for a write operation rather than just > a read operation to each page? Was it just a developer's naive > presumption that the pages must be immediately copied rather than > just fetched? It depends on how COW is implemented in z/OS UNIX. > Will TM perhaps cause pages that have previously been loaded, then > paged out, to be re-fetched, perhaps unnecessarily. Yes. Referencing a valid, but paged out, address causes a page fault and normal page fault handling will cause the page to be fetched into real storage by ASM. > Even prior to the advent of PROGxx REFRPROT, weren't refreshable > load modules from an authorized STEPLIB loaded into a write- > protected key? If so, it's surprising that the problem didn't > surface earlier or that it does not occur even in the absence > of REFRPROT. Not exactly. There's no such thing as a "write protected (storage) key". PSW key zero trumps any storage key - provided that the store-protection feature is not in effect for the target page. Store protection is an attribute of virtual translation structures (page, segment, region etc.) If the protect bit is set, then any attempt to store into that page causes a S0C4-4 no matter what the PSW key is. Prior to REFRPROT in z/OS 1.9 (thanks for reminding me Ed!) contents supervision ignored REFR. Reentrant modules that were loaded from unauthorized libraries were always loaded into normal (i.e. not store protected) subpool 251 job step storage, as were all non-reentrant modules regardless of where they were loaded from. Modules loaded from authorized libraries were always loaded into key zero subpool 252 job step storage. That was not store protected either, so code in PSW key zero could scribble on it but any non-zero PSW key would get a S0C4-4. I am not sure how REFRPROT is actually implemented. If it's just using protect key zero as a surrogate for write-protection, then it would a lame-ass non-solution. But that would probably have been much easier to implement since there would be no need to worry about rounding up the program load area to a page multiple. > What happens if the parent process LOADs a module (not necessarily > eligible for deferred page loading) prior to fork(), then after > the fork() either the parent or the child, but not both, DELETEs > that module? I suppose that if the Content Supervision entries > are copied (or COW) on the fork() things simply work. That would be the point. In theory the child process has its own independent view of the process memory it inherited from the parent process. The whole fork() idea was based on a naïve optimization that didn't ever really work out as well as the UNIX designers hoped. COW was just the ugly gun most UNIX kernel implementers chose to shoot themselves in the absence of specific hardware support for COW-like functionality. By write-protecting logically shared pages the OS ensures that there will be an interrupt if any of the sharing partners attempts to change a page and at that point, the OS can step in and make a separate physical copy of the original page for the changed data to go in. Sounds easy enough right? CC ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
