Overlaying of Storage key

[jaggz]

Hello All,

Its just a general question for knowledge sake. Under what are the circumstance the storage keys are overlaid in the system i,e.. any Badly written program which does this problem ?

Any enlightment would be highly appreciated.

Jaggz

[steve-myers]

Certainly a badly written program can overlay storage keys, but it would be difficult. The last time I, personally, did anything with storage keys must have been more than 40 years ago when I keyed in (from the operator's console) a tiny program to investigate what appeared to be storage key problem with some brand X LCS memory connected to a 360/75. Since the primary drivers of S0C4 ABENDs these days are page faults or low storage protect issues rather than traditional storage key faults, people just don't think in terms of storage keys very often. I'm too lazy to bring up a POP, but aren't SSK/ISK real address driven rather than virtual address driven?

[enrico-sorichetti]

You do not overlay storage keys, You overlay storage.
The storage keys are a way of protecting storage from being overwritten

see
ABCs of z/OS System Programming Volume 10 - IBM Redbooks
http://www.redbooks.ibm.com/abstracts/s ... .html?Open

[steve-myers]

Mr. Sorichetti is correct in the sense that only SSK/SSKE type instructions can set storage keys; ordinary instructions cannot touch (or read) storage keys.

[enrico-sorichetti]

but aren't SSK/ISK real address driven rather than virtual address driven?

SSKE and ISKE both expect REAL addresses

there is a IVSK which expects a VIRTUAL address

my previous comment was about normal programs ...
I wonder how many application only programmers are <aware> of the storage keys mangling instructions

[steve-myers]

... I wonder how many application only programmers are <aware> of the storage keys mangling instructions

Probably not many.

[dick scherrer]

Probably best that most do not - especially fearless newbies . . .

It might be considered a "feature" to try and exploit

d

[jaggz]

Hi,

As usual you guys have given a great knowledge. Thanks a lot again. Objective behind my question was some time back in our shop an application programmer ran a program which overlaid the key storages and we understood from the dump.


Jaggz

[steve-myers]

Hi, ... Objective behind my question was some time back in our shop an application programmer ran a program which overlaid the key storages and we understood from the dump. ..

This makes absolutely no sense. All programs have some sort of "key storage" - either the program text itself or data, or both - that the program must have to run properly. This has absolutely nothing to do with storage keys used for storage protection. Most programs alter in some fashion, this storage. It is quite common for programs to improperly alter this storage because of errors in the program; this may account for the "overlaid the key storages" statement

In MVS and z/OS, most user programs are run using program and data in storage protected using key 8. For the most part a program running in key 8 in address space A is protected from a program running in address space B, also in key 8, by the paging hardware, even though the two programs frequently use common virtual addresses. I have been using MVS and z/OS systems for nearly 40 years, and I cannot recall any incident in which a problem state key 8 through 15 program accessed data in another address space.

Some programs are run using storage keys 0 through 7. There are several ways these keys are assigned which I won't discuss here. Collectively these storage keys are considered "authorized." There is only one way, to the best of my knowledge, which I will not discuss here, that an otherwise unauthorized program can be run using storage keys 0 through 7. This method is very tightly controlled, for obvious reasons.