<snip> I have an ordinary problem state program that attempts to access storage
that it does not have access to. Obviously a S0C4 is the result. Let's say the address is a valid virtual address (but the storage key is wrong) and the page representing that virtual address is paged out. What is the sequence of events that leads to the S0C4? Does the OS have to page in the page so the hardware can generate a S0C4? That seems inefficient. And in any event, whatever the mechanism, why could not that mechanism generate a condition code for this hypothetical new instruction rather than a program interrupt? </snip> There has to be a program interrupt. Because that is the hardware's way of telling the software "I do not know". The hardware does not know anything beyond that the DAT structure indicates that the page is not valid. Is it "truly not valid" or is it "not valid because the OS has paged out the page"? The software could choose to provide a way to field that program interrupt and convert it into something that continues the user program. That is, after all, exactly what happens on a page fault. z/OS would not do that because it would not be a useful expenditure of resource. Taking a long time to field a user error is hardly a problem in any realistic situation. After all, the same user could have simply blown up themselves if they wanted to do so, without involving your service. So the net effect to the system is the same. As to the question about the flow, it's something like this: * Program/instruction references storage via a virtual address * Hardware determines that the virtual address is not backed by a real page and presents a program interrupt (there are quite a few possible such interrupts * OS program interrupt handler sees that program interrupt and queries its own data to determine if the reason that the virtual address is not backed by a real page is because the page has been paged out to some form of auxiliary storage * OS would generally let the fault continue to some recovery process if the page is not available on aux * If the page is available on aux, OS would generally suspend the program, bring in the page from aux by some asynchronous process (it can be synchronous for such cases as DREF or SCM in which case suspend/resume would not be needed), then resume the program to "try again". The desire to "try again" is why these program interrupts occur without a PSW address update, allowing for easy "try again". So, sure, in the middle of the above the OS could have said "the page is on aux, but I'm not going to bring it in, and if I can tell that the instruction being issued was some new "test only" instruction then set up to continue the interrupted program with an indicator such as a condition code (or anything else it chose to make the interface, even a "return code"). This is not instruction architecture. This is software programming interface. z/OS would not mplement such a thing. There is no guarantee even that the operating system can determine the instruction. That information is not part of program interrupt information, and it is theoretically possible for the page(s) with the instruction to be paged out by an asynchronous process before the program interrupt handler could look. Just about the only productive use of TPROT is when you are supervisor state and have reason to know that the storage being accessed is supposed to be page-fixed. In that case a CC=3 from TPROT can be known to indicate "bad". z/OS itself uses this sometimes. Peter Relson z/OS Core Technology Design
