On Wed, Dec 16, 2015 at 12:18 PM, Gary Weinhold <[email protected]> wrote:
> Thanks for your extended response. I agree that it is unlikely BSA will > be any part of my resolution. > > I was testing ways to avoid running in key 0 while accessing and updating > memory in different keys. I saw that BSA could change the PKM and so was > testing how it worked. This experiment was with key 9 because I knew it > was available for CICS support and was curious if it had fetch access to > key 8. It doesn't but then I wanted to know how BSA worked. > > In response to your and John's more extensive inquiries into comments on > my larger goal: > My larger problem is having to update key n memory (where n is 1 to 7) and > in the same routine access and update key 8 or key 9 memory efficiently. > To minimize integrity exposures, I'd prefer not to run in key 0 except when > the rare update to key 0 CSA is required. When I started to investigate > this change the first hurdle was that user key storage is by default fetch > protected so I could not run in key n while updating key n memory and still > access key 8 memory. This is a modification to existing code from when > the key n memory was key 9, so the accesses and updates to key n and user > key are interleaved. > Have you considered MVCDK, MVCK, or MVCOS? They are semi-privileged. So you can move data from memory to memory with differing keys so long as the key(s) are in the PKM. E.g. you could be running in PSW key 8, and move data from key ? to key ?? so long as both ? and ?? are in the PKM. > > Regards, Gary > > > Gary Weinhold Senior Application Architect > -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown
