Shmuel posted the relevant section. The really relevant point is that subpool 251 is fetch-protected (and subpool 252 is not) If you switch out of the subpool 251 key (and the module is in subpool 251 storage, not subpool 252), then you have no access to the storage of your program and thus, yes, you will program check attempting to fetch the instruction.
If your program is loaded into subpool 252 (key 0, not fetch protected) any key can read it. <snip> when a blob of AUTHORIZED code loads something, say, some system exit or something; what is the STORAGE KEY of the memory that code is loaded in. That program may get entered with a KEY=0, but will need access to its own CSECT. </snip> The same rules apply. May I ask why you need to switch to key 9? That is very atypical. I believe that the Storage Protect Override facility, as implemented in z/OS with Key 9, was created so that CICS transactions could avoid accidental overlays of CICS key 8 storage. So unless you're trying super-hard to prevent yourself from overlaying your own key 8 storage, you would not typically get into key 9. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
