× 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: RE: MATCTX (was Detecting changing objects...)
  • From: Leif Svalgaard <l.svalgaard@xxxxxxxxxxxxx>
  • Date: Fri, 19 Nov 1999 13:43:58 -0600



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


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.