Re: STORAGE KEY of loaded executable
Flushing the pipeline is a trade-off between complexity and performance. It's certainly possible to design a pipeline that can handle key changes without flushing; whether it's worth the real estate is something that your engineers have to decides. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Peter Relson [rel...@us.ibm.com] Sent: Wednesday, February 3, 2021 8:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STORAGE KEY of loaded executable It's not so much the instruction cache but rather the instruction pipeline that might need to be flushed. As Ed Jaffe pointed out, anything done speculatively needs to be, and is, re-evaluated (in general, thrown away and re-done). 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: STORAGE KEY of loaded executable
I dimly recall from decades ago a recommendation to run CICS in key 7. IIRC, it had something to do with aligning a buffer on a page boundary. Long obsolete advice, I'm sure. == Peter Relson wrote: >. > > >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
Re: STORAGE KEY of loaded executable
It's not so much the instruction cache but rather the instruction pipeline that might need to be flushed. As Ed Jaffe pointed out, anything done speculatively needs to be, and is, re-evaluated (in general, thrown away and re-done). 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
Re: STORAGE KEY of loaded executable
Implementation is model dependent. The hardware has to preserve enough information to comply with the architecture. I know of no reason for MVS to purge the i-cache under normal circumstances. If the I-cache includes key and STO then I know of no reason not to share it. There is no need to validate the key in the cache after SPKA; what is necessary is to vallidate if prior to final execution. Consider code that sets the key to 8, does something, then sets the key to 9. Do you really want to invalidate and refetch the second block of code after the first SPKA. Now, the designers have to make tradeoffs between circuit complexity and performance, so there might be purges that are not logically necessary. But, again, such matters are model dependent. If there is speculative execution and an instruction is not in the right key, then it has to be rolled back. But it's only the last key change before the instruction that matters. -- 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: Tuesday, February 2, 2021 7:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STORAGE KEY of loaded executable On Mon, 1 Feb 2021 13:45:45 + Seymour J Metz wrote: :>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. How does the cache work? Does MVS preserve the I-cache if a different thread is executing the same address (or share the I-cache between different CPUs)? Does it validate that the source of the cache is accessible whenever the SPKA is issued, i.e., does the cache have key and fetch protect bits? Any pre-executed instructions will have to be rolled back, correct? -- Binyamin Dissen http://secure-web.cisco.com/1g-7fia0NcdlvAUroS_CZ7R2AV8DyMZE3b1LPPPJTzH79cOlOAeTaBWLpdK2p0t96V4ZtMYCXOScGlyngDF2ZCOcp37oXfcQ0DvM7CZE2DFnVQVu8OpKrEDMF_0adlAYM4D1vkL4UDIECC4TVpSFHAtakw5toKlh_6kp0QNMiP98Vzt-5RUhWDlhSGp2PhvtrpMXZKOGvIp_v5GYPGcUoZOMgFCb2tSNheQPRnw4--qvNLzW3owJLyusoxUr12y3ShiwjXHPKX93BdEvFHgG2jn7H-HOPaqTZSHGPJ9it92SaHFGlfQoavXI5kbLm3XYX7hpsvr7aIVeroAui8xPzsnHh0ZYB7LksDt0p5E4kJQ8E6gAukjDTWMCYbVOwv-G3Ltle8YBZjLt-NqDaENkcTAwg0Xuv9-utb8O_dL8o-pkecpsQhf2YV-MRZGOX3LoT/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
Re: STORAGE KEY of loaded executable
I'm playing around with some tests and was switching keys, and didn't want to mess with authorized code. So I just picked the next one up to 8. There was nothing "special" in my choice of 9. Then you were playing with fire (well, program checks) and were kind of lucky. The only key that a non-APF-authorized key 8 program can switch to is 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
Re: STORAGE KEY of loaded executable
On Tue, 2 Feb 2021 05:39:36 -0800, Ed Jaffe wrote: >... >> Does it validate that the source of the cache is accessible whenever the SPKA >> is issued, i.e., does the cache have key and fetch protect bits? >> >> Any pre-executed instructions will have to be rolled back, correct? > >Results of instruction fetch, instruction decode, address generation, >operand fetch, etc. down the "wrong" path are discarded. > Does this neutralize even the Spectre exploit? https://xkcd.com/1938/ -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STORAGE KEY of loaded executable
On 2/2/2021 4:21 AM, Binyamin Dissen wrote: On Mon, 1 Feb 2021 13:45:45 + Seymour J Metz wrote: :>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. How does the cache work? Does MVS preserve the I-cache if a different thread is executing the same address (or share the I-cache between different CPUs)? Just to be clear, what he's talking about has nothing whatever to do wit MVS or any other operating system. It's the IBM Z processor hardware doing this... Does it validate that the source of the cache is accessible whenever the SPKA is issued, i.e., does the cache have key and fetch protect bits? Any pre-executed instructions will have to be rolled back, correct? Results of instruction fetch, instruction decode, address generation, operand fetch, etc. down the "wrong" path are discarded. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STORAGE KEY of loaded executable
On Mon, 1 Feb 2021 13:45:45 + Seymour J Metz wrote: :>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. How does the cache work? Does MVS preserve the I-cache if a different thread is executing the same address (or share the I-cache between different CPUs)? Does it validate that the source of the cache is accessible whenever the SPKA is issued, i.e., does the cache have key and fetch protect bits? Any pre-executed instructions will have to be rolled back, correct? -- Binyamin Dissen http://www.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
Re: STORAGE KEY of loaded executable
Peter Relson wrote: . 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 Hi Peter! I'm playing around with some tests and was switching keys, and didn't want to mess with authorized code. So I just picked the next one up to 8. There was nothing "special" in my choice of 9. Same kind of idea - trying to just switch to key 9 and make sure things don't blow up, or accidently reference the previously allocated key 8 memory. But I bumped into some references to the previous memory that are intentional/needed... so it's a bit of a squirrely mess at this point. - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STORAGE KEY of loaded executable
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. 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. 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
Re: STORAGE KEY of loaded executable
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 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 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
Re: STORAGE KEY of loaded executable
Using the REFRPROT statement Use the REFRPROT statement type to specify that REFR programs are protected from modification by placing them in key 0, non-fetch protected storage, and page protecting the full pages. Therefore, any parts of the program that are on partial pages are not page-protected. For more information on protectionof REFR programs, see z/OS MVS Program Management: User's Guide and Reference That's Shmuel -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Thomas David Rivers [riv...@dignus.com] Sent: Monday, February 1, 2021 7:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STORAGE KEY of loaded executable Binyamin Dissen wrote: >On Sun, 31 Jan 2021 18:34:11 -0500 Thomas David Rivers >wrote: > > >:> 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. > > I have to admit to not looking for it yet - but do you have a pointer to the doc for this? Schmuel described the various Subpools and fetchability attributes which I was able to find via a google text search. These seem to be described in the ATTACHX documentation... but that must also apply to LOAD (I suppose???) Thanks for the pointer about REFRESH (REFR option on binder), I'll look for more info. The downside of REFR is it defeats the use of debuggers which modify the code-stream to insert break-points... but, it is what it is... - Thanks - - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://secure-web.cisco.com/1Fca2f4IZyQDVYdr-tstJBM0QiKvOzgzg94WT2h048B5kcwGwpOyiewu9F8yc-DmUE5IxyEX1shdLcwKPemLt6F9sCyPfueLpjDx_8DxXMbGz9S-e_C70qlP4OQjP3eYcoaQoC_iERsWYwJDrhfxOUh1J8gFjYF9kMnNKgf8Nrj8yK4Xb4Ge0Reg3P-yKKCVRlaQztNOgDRtszxarzAZobwBPk07aruzQDx89h57i2M96Hbq9jVg_wS7-tHzzf9H5dtt5uvH51UVkSr6kOGU0WalGJCuZYzWtJ7t2-Sb1QarOI8Mlzh40ZvO2iGhVnKMwICQMQ_BqdW2QV9I8IamrAtmJuB_-kGFQeGa-nCbuqB5vlLyh5T_sR5IZbV4twskfvJf-TmGDMkKun49waLNkEgbHfD3iep5-o0pMk0wwfoP_1ZZ4Rd5AJXk4o8wjmpoo/http%3A%2F%2Fwww.dignus.com -- 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
Re: STORAGE KEY of loaded executable
Binyamin Dissen wrote: On Sun, 31 Jan 2021 18:34:11 -0500 Thomas David Rivers wrote: :> 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. I have to admit to not looking for it yet - but do you have a pointer to the doc for this? Schmuel described the various Subpools and fetchability attributes which I was able to find via a google text search. These seem to be described in the ATTACHX documentation... but that must also apply to LOAD (I suppose???) Thanks for the pointer about REFRESH (REFR option on binder), I'll look for more info. The downside of REFR is it defeats the use of debuggers which modify the code-stream to insert break-points... but, it is what it is... - Thanks - - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STORAGE KEY of loaded executable
On Sun, 31 Jan 2021 18:34:11 -0500 Thomas David Rivers 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 http://www.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
Re: STORAGE KEY of loaded executable
"In this case, the control program places the module in subpool 252. When choosing between subpools 244 and 251. the control program uses: • Subpool 244 only when within a task that was created by ATTACHX with the KEY=NINE parameter • Subpool 251in all other cases Subpool 244 is not fetch protected and has a storage key equal to your PSW key. Subpool 251 is fetch protected and has a storage key equal to your PSW key. Subpool 252 is not fetch protected and has storage key 0." -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Thomas David Rivers [riv...@dignus.com] Sent: Sunday, January 31, 2021 6:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: STORAGE KEY of loaded executable 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? When you switch KEYs, how do you retain access to the program's memory for constants and things? 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. 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? - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://secure-web.cisco.com/14WxsDY-ayEIw4Txd4CUMcWempgt1bm-X7QTZLrVnB1i6y_TA8841bEosQ2fvFaGtux7s2inbpaPacpuiMargzng8gwxFV5gOEoaTqqAVgLlVYVvpTX2b8HEPP7qMh32meHrzoDeYi2YlVQSamQ6-5nyyePmZACHdPPnhUvNFSMsPQLj-4l8ESe4ScBrJfxBMIHHKL2yQwzbh8HI3XoyU_GR8mttfo6SMzk6InfeXYnQxY4NusZuxHoEyR2dPPaP-Z-X9x6iVDSEyz0XmBMh2V9XS7D-WNOSRJI_UP0aL0jgj67GzxbodARuYB0l7Spm8fL2KJjam5mKuznS8nPE3NzMsL-xju1mRq3tY0IrtZmxs7JWt_YMmIWy1oG3T82MK-nf30qmZ5Ad5Hnoaw941mHq5tx8ddGWQ_fD4wybqxyPy0EysALY5YXjajS7ipLcO/http%3A%2F%2Fwww.dignus.com -- 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
STORAGE KEY of loaded executable
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? When you switch KEYs, how do you retain access to the program's memory for constants and things? 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. 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? - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
