> The short question: > What is the most effective (fast) way to move data between different > storage keys ?
On z machines there is only one move instruction in hardware (MVC) and all of the other variants are implemented in milicode. So for a given amount of data and a particular set of environmental state (alignment, key etc) they are all going to take just as long as they need to and it will always be longer than MVC. So the fastest way to get data from one key to another is to switch to key zero and use some number of MVC instructions. But I don't think that being fastest is the bestest when you have to get data from one key into another. You have to consider data integrity. If you need to move data into a key other than the one you're running in, then you MUST use one of the key crossing moves (MVCSK, MVCDK, MVCP, MVCS etc) where the program has to specify the source or target key. And don't just do an IVSK on the target area to get that key. Use what you know (logically) the key to be (typically your caller's PSW key.) Then at least, if the area you have been passed is not in the key you expect, the move will program check rather than overlaying some other poor fool's data. > The longer story: > We have an FSS application ( running in JESKEY) which starts different > user programs, and exchange the data with the user programs > (via SVC screening and access method routine changes ) When you say "starts user programs" what do you mean and how do you do it? > For a long time, the user application was also run in JESKEY.. Was this application intended to be run as an authorized user program? > Since a year, the user applications started to use the shared memory > (over Uss) and we found, it is necesary to run in key 8 to use shared > memory It is not necessary to run in key 8 to use shared memory. > So now the user applications are running in key8 , and we are using PC > routines to go into JESKEY, and MVCSK and MVCDK to move data. You have probably created an integrity exposure unless you have been particularly careful about validating the caller's parameters. > It is working so, but the CPU consumption is much higher as it was before. The PC and the PR should be negligible unless you do that function with very high frequency. Otherwise the CPU cost ought to be about the same. What else changed? > How can I solve this ? > Can I use here KEY=NINE (Storage Protection Override) . Not a good idea. That just lets key 9 programs fetch and store in key 8 (or is it the other way around?) anyway, probably not what you want here. CC ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
