MATCTX (was Detecting changing objects...)

[bvining@xxxxxxxxxxxx]

Lief,

It is my understanding that back in the V2R3 time frame a decision was
made to disallow the usage of system pointers to system domain objects
when in user state and security level 40 or above is in effect.  This
decision was implemented in the machine by checking the object domain
(or hardware storage protection associated the addressed storage) when
dereferencing the pointer (that is, touching the object).  Due to this
a whole lot of "unblocked" MI became effectively blocked at levels 40
and 50; though please note that the instruction itself did not
necessarily change -- it was implementation of dereferencing the
pointer that did.  What drove this decision (domain checking) was the
desire for greater security, integrity, auditing, etc.

It is due to this blocking at higher levels of security that IBM
developed the wrapper API (QusMaterializeContext); it is not the case
that IBM disallowed the instruction because the API existed.

So the total function of matctx is not available at all security
levels due to the implementation of domain checking (it was nothing
personal about the instruction :-)) and to re-instate that function
would be to create special case exceptions in how pointer checking is
conducted in the machine on an instruction by instruction basis; which
is a path that no one I know of really wanted to go down.  As an
alternative IBM instead came up with the API which provided the matctx
data in a format that would not require alot of rework by developers.

I hope this helps clear things up,
Bruce

>
> [Leif Svalgaard]  Then explain *why* MATCTX at levels 40 and 50
>gives
> a protection violation while the wrapped API does not. Not *how
>come*.
> That I understand fully (the API being a system state program), but
>*why*
> with the API available it was deemed necessary to disallow MATCTX
> directly?
>
> [Leif Svalgaard]  I'll try from this angle: Since an API is
>available
> why is the function not directly available? What is the rationale
>for
> disallowing the direct function in user state programs and at the
> same time supplying an API with the same function that allows
> the developer to do it anyway?
>
> [Leif Svalgaard]  One more time:
> Why is this function not available directly?
>


+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---