The real problem is the time of check to time of use window, Putting your code in the scope of a recovery service and using, e.g., MVCK, resolves that issue.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Dan Greiner <[email protected]> Sent: Monday, June 3, 2024 11:29 PM To: [email protected] Subject: Re: The best way to check any virtual address Virtual-storage accessibility is an issue about which the Systems Architecture team was often asked, by customers, ISVs, and IBM developers. At a SHARE presentation in 2009, I dragged out my FrameMaker instruction template and designed the IS IT SAFE (IIS) instruction in about 5 minutes. IIS was a simple RXY-format instruction where the second operand designated a storage location, and the first operand was ignored. The condition code was set as follows: CC0 Storage is accessible for both fetch and store. CC1 Storage is accessible for fetch only CC2 Storage is not accessible The most important part of the instruction description was the programming note: This instruction is absolutely useless! Why? Because the CPU is clueless as to whether a dynamic-address-translation (DAT) exception is due to the virtual address being paged out by the OS, or a DAT exception is due to the virtual address being totally bogus. Only the OS can tell you that correctly. I also recall that various OSes have service routines to provide such information, but I don't recall what they are. Part of the initial design criteria for transactional execution was to efficiently provide a means by which a program could speculatively touch a virtual address, and if the transaction aborted, then pretend you didn't mean it (... my bad ... do over). Regrettably, in their finite wisdom, IBM has put the coffin nail into nonconstrained TX.
