RE: MATCTX (was Detecting changing objects...)

The V4R2 functional reference manual does not mention any
restrictions. Anyway, I still don't have a *rationale* for why
an obvious security breach is allowed in C and not in MI.

As I mentioned in my post it is*obvious* that it would work
with the C-program because at the bottom of the API it
is a system state program that executes the MATCTX.
What is not obvious is why *this* breach is allowed.
So my question still stands. It is not about "how",
but about "why"?

> -----Original Message-----
> From: bvining@VNET.IBM.COM [SMTP:bvining@VNET.IBM.COM]
> Sent: Friday, November 19, 1999 10:21 AM
> To:   MI400@midrange.com
> Subject:      MATCTX (was Detecting changing objects...)
> 
> If MATCTX was working prior to V4R3 for explicit libraries then the
> bug is in the previous releases and not V4R3.  For many releases
> there has been a restriction concerning passing system pointers to
> system domain objects from user state programs (at higher security
> levels); I suspect it is this restriction (the explict system pointer
> to the context/library) that is causing the failure.
> 
> Because of this IBM provided the API QusMaterializeContext (you can
> probably guess what it does based on the name) back in one of the V3
> releases (it's in the V3R7 manual anyway).  This API is documented in
> the Object APIs chapter of the System API Reference (though it basically
> points you to the MI Functional Reference as the API is just a front end
> to MATCTX that puts you into the proper state).  Other front ends of
> this type exist, such as QusMaterializeJournalPortAttr in the Journal
> and Commit APIs chapter).
> 
> Bruce
> 
> >
> >A problem with MATCTX is that from V4R3M0 it seems to be
> >a restricted operation (except when materializing the machine
> >context - * ) and gives you a protection violation at security
> >level 40 and above if your program is a user state program.
> >Interestingly enough, the C function matctx does not have
> >that problem. (I can hear the C-bigots snicker already).
> >This is because the C interface goes through a service
> >program that is not a user state program. As far as I am
> >concerned thus is a bug. It does not make sense to
> >have a restriction that is that easily circumvented. Maybe
> >the bug has already been fixed in V4R4M0. If not, it
> >either should be fixed or it should not be a restricted
> >operation.
> >
> 
> 
> +---
> | 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
> +---
+---
| 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
+---