The behavior for REFR is subject to operator and parmlib control. RENT goes into key 0 if the library concatenation is APF.
There's no reason to flush the cache, and doing so would be a major performance hit. With luck there an IBM Systems Journal article or redbook on the I-unit of current processors; if not, there should be. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Binyamin Dissen [bdis...@dissensoftware.com] Sent: Monday, February 1, 2021 6:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STORAGE KEY of loaded executable On Sun, 31 Jan 2021 18:34:11 -0500 Thomas David Rivers <riv...@dignus.com> wrote: :>I have a situation where I LOAD a program, with a PSW KEY of 8, :>then branch to it. :>The program switches to KEY 9, but wants to reference some :>data in the loaded CSECT (say, for example, a =F constant in the :>literal area.) :>This blows up, I'm guessing because the key isn't the same as the :>loaded module's memory (the address appears to be fine.) :>This brings up a couple of questions: :> When you LOAD a program, how do you control the KEY :> for the memory the LOAD'd program occupies? Can you, or :> does z/OS always LOAD (non-auth) programs in KEY=8? If you mark the module refreshable it should nowadays be loaded into SP=252 which is not fetch protected. :> When you switch KEYs, how do you retain access to the :> program's memory for constants and things? IF the program is in fetch protected storage, you do not (as you saw). :> And - to get more complicated - 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 :> it's own CSECT. Well, there MVS acts as a sort of nanny and if you ask for SP=0 when in key zero it really gives you SP=252. You need to specify SP=250 if you want task zero. But the STORAGE macro certainly allows you to allocate storage that you do not have current access to, such as a supervisor state program in key 1 can allocate key 3 or key 8, and should it make an improper reference to the storage it will PIC-4. :> And - It's not quite clear to me, but does the STORAGE KEY :> get examined during the fetch-execute cycle of program :> execution. If my module is in memory with KEY=8, and I change :> the key with an SPKA instruction; can I actually retrieve the :> next instruction to execute? Just where does the key-check occur? I notice that the POPs does not say that it causes a flush of the instruction cache but it would have to do something similar for integrity. Changing the PSW key to something that does not have the ability to fetch from the PSW location should cause a PIC-4. -- Binyamin Dissen <bdis...@dissensoftware.com> http://secure-web.cisco.com/1rk1kzDQ1dsQLEjbFIOdTLgfWKkMk_vMLQiQ6XbnsMve7RFps3Az-Pvi4Ha4_hhLa58Bzcqo3XlG-W4hVLLUB3ZQa1if0tXXo1yla2P3yhSSIYHKPbxfM4X4GeupcpCBAHhazrlRh9D_qk0pV21XDo9ZZypKN_56nB7leTnW_YhTD1ZSoHHcAsN2SX4U4ppIoQtsvEfQgYUs7sqaQXlLrFSwLvpG-a0Y6j_Ki2pog7LntjtEqUi_Hz0-ry0_Xu_zBCRC7mcBJLBp-7k4wBcuax_tDlfokH9M4LwOmIanp541XIxipkGLJEhyC3mY_Xo8aX3T4JKW88vZ_cb6NHHLV4d70zPgf9t0zFFv87-RLIU6-DBAF2XuDLlLdH1t4HKttl5ebSFWJVNifKH-KB65KoACP6YVEDl-DuOsK0-BIFPcysrLi3oRlSOUvXrzhMOJg/http%3A%2F%2Fwww.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
