On Mon, 27 Mar 2023 at 20:11, Gary Weinhold <weinh...@dkl.com> wrote: > > It may be possible to devise a slip trap that would exempt the master TCB, > but it might catch many perfectly legitimate problem state accesses, like to > access the CVT to start a pointer chase to an IBM or ISV service or control > block.
I agree, but there are a couple of problems. As you say, if the application TCBs issue any of many perfectly ordinary service calls, they may run afoul of ZAD. But also, the OP's example LA R5,1 MVC TARGET,0(R5) won't be caught by ZAD, because the register contains a non-zero value. Whereas LA R5,0 MVC TARGET,1(R5) would be. In that sense ZAD will catch only an overlapping subset of the problems compared to the FLAG(PAGE0) assembler option already tried. I'd say that if these application programs are full of this kind of classic error (my old favorite is MVC BYTE,C'A'), there's nothing for it but to read through them slowly and carefully. I suppose if the application programs are known not to use any z/OS services at all, then an extreme approach would be to turn off the Fetch-Protection-Override Control (bit 38 of control register 0) upon dispatch of the application TCB, and hope that there's opportunity to turn it back on again when the TCB loses control. I don't suppose there are general-purpose TCB dispatch and return exits(?), so possibly this would require running the application disabled for interrupts. Well this is kind of fantasy debugging that is not going to work on anything but the most sandboxed environment, and probably not even then. But it does suggest that if these applications are really doing application processing with no reference to system services, then perhaps they could be run under an emulator such as z390 or even the ASSIST environment, where more detailed handling of those page 0 refs could be implemented. Tony H.
