Okay, thanks all, and especially @Peter. 1. There is no burning need for such a facility. There already is an existing facility. If you are going to be accessing storage for which your access rights are questionable, use ESPIE. QED.
2. Basically, the problem with the instruction approach is that the OS is well-equipped to respond to an instruction with an interrupt; it is not well-equipped to respond with a generated condition code (for the reasons @Peter elucidates). The OS is not at all well-positioned to determine the failing opcode. I suppose if there were a burning need for such an instruction, the hardware would need to indicate in the page fault interrupt that it was the new instruction and required special treatment from the OS. If I am parsing things correctly, a hypothetical new instruction could readily deal with the "page exists, wrong key" situation -- on after-page-in retry it could just return the appropriate return code. It is the "no such virtual address" case that has the (purely software) problem above. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Peter Relson Sent: Sunday, March 6, 2022 5:34 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing Address validity <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.
