We had lots of z/OS specific/centric/oriented/triggered/influenced
threads here - so I do not feel too bad in explaining the protection
scheme as is it in z/VSE. It is very much like its origin DOS -

BUT

-it is an op-sys that was born on a 360 and hence utilises memory
protection (as well as the other things that come with that
architecture and the improvements over time).

Original DOS used key 0 for the op-sys and some programs dynamic
loaded into the SVA (LPA in z/OS). This is still the case.

All other partition have/had a unique a unique protection-key - No big
deal we are looking at a max of 12 partitions (if you have 16 different
protection keys). All in one address-space of 16 MB.

When a something is dispatched it is usually dispatched in partition-key
(different for whatever partition it is). Op-sys and some privileged
functions are dispatched in key 0 (this is oversimplified- but enough
for the discussion).

With the introduction of multiple address-spaces (with a very short
period of multiple partitions in one space) protection-key became
obsolete (at least for protection one from the other except the
op-sys for itself). z/OS is aware of that and reserved ony one key (80)
for average users.

Before the advent of dynamic partitions we had a VSE with different
protection-keys for each of the partitions it supported (BG=10, FB=20
FA=30 F9=40 F8=50 F7=60 F6=70 F5=80 F4=90 F3=A0 F2=B0 F1=C0).

Since the advent of dynamic partition all of them are created with
the same protection key (D0).

With this scheme in mind- I do not understand why creating data in
common storage with key 90 (on a system that always has CR0 bit 39 on)
is a bad thing (other than that it is vulnerable - but, hey, it is my
data).

To me it is much safer to create (transient) data in key 9 and
let every one over it, as opposed to create it in key 0 storage and let
everyone for updating into key 0 (yes- that is the way it is - z/VSE
is not z/OS).

--
Martin

Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de

Reply via email to