× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: MATCTX (was Detecting changing objects...)
  • From: bvining@xxxxxxxxxxxx
  • Date: Wed, 24 Nov 99 15:24:07 CST

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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.