Re: setsppfp crashes with MCH6801

Thanks a lot for pointing to the QSYRTVSA API. Indeed security level still is set to 40 but pending to 
be changed to 30.

I will think about to use DSPBNDDIR instead of using setsppfp(). Your idea of storing the last changed 
timestamp of the binding directory might be the key.

Thanks a lot for your help.

Thomas Raddatz.



Bruce Vining schrieb:
> You could confirm the active security level with the Retrieve Security 
> Attributes (QSYRTVSA) API.  It returns both the current and pending 
> security level.
> 
> And if you're concerned with performance of using an *outfile have you 
> considered retrieving the *BNDDIR object description and checking to see 
> if the object has been changed since the last time you generated the 
> outfile?  If not you could bypass the DSPBNDDIR, and of course you could 
> also just load the results of the DSPBNDDIR (when changes do occur) into a 
> more convenient object (*usrspc for instance).
> 
> You really do not want to be building new code for production use that 
> depends on running system state.
> 
> Bruce Vining
> 
> 
> 
> 
> Thomas Raddatz <[email protected]> 
> Sent by: mi400-bounces-Zwy7GipZuJhWk0Htik3J/[email protected]
> 05/09/2006 10:55 AM
> Please respond to
> MI Programming on the AS400 / iSeries <mi400-Zwy7GipZuJhWk0Htik3J/[email protected]>
> 
> 
> To
> MI Programming on the AS400 / iSeries <mi400-Zwy7GipZuJhWk0Htik3J/[email protected]>
> cc
> 
> Subject
> Re: [MI400] setsppfp crashes with MCH6801
> 
> 
> 
> 
> 
> 
> Thanks a lot for your detailed information. QSECURITY shows 30. But 
> probably you are right that it was 
> changed back from a higher level without any IPL. I will check that 
> tomorrow and let you know about it.
> 
>  > Your technique will not work at higher security levels. You should find
>  > an alternative method. The DSPBNDDIR command supports *OUTFILE. You'd
>  > be better off using that.
> 
> *OUTFILE is too slow because I have to randomly check for and manage 
> specific entries.
> 
> Thomas Raddatz.
> 
> Simon Coulter schrieb:
>> On 07/05/2006, at 3:34 AM, Thomas Raddatz wrote:
>>
>>> I have a program that utilizes setsppfp() to get a pointer to the 
>>> associated space of a binding
>>> directory object. It runs fine on our development box as well as on 
>>> our production box. The program
>>> crashes with MCH6801 on our test box which is another LPAR of our 
>>> production box. The violation type
>>> is 1 = Object domain violation.
>>>
>>> Both LPARS (production and test) are at security level 30. As far as I 
>>> know the production LPAR is
>>> DBCS and the test LPAR is SBCS. Both LPARs are at PTF level TL05298.
>> I presume the LPARs are on the same version of OS/400?
>>
>> The MCH6801 indicates the failing partition is NOT running at security 
>> level 30.
>>
>> Are you positive the security level on the failing LPAR is 30? The 
>> QSECURITY system value may show 30 but it may have been changed. If it 
>> was originally at a higher level that will still be in effect unless 
>> the partition has been IPLed after it was changed. Perhaps you should 
>> arrange for the partition to be IPLed just to be sure.
>>
>> Your technique will not work at higher security levels. You should find 
>> an alternative method. The DSPBNDDIR command supports *OUTFILE. You'd 
>> be better off using that.
>>
>>
>> Regards,
>> Simon Coulter.
>> --------------------------------------------------------------------
>>     FlyByNight Software         AS/400 Technical Specialists
>>
>>     http://www.flybynight.com.au/
>>     Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
>>     Fax:   +61 3 9419 0175                                   \ /
>>                                                               X
>>                   ASCII Ribbon campaign against HTML E-Mail  / \
>> --------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> This is the MI Programming on the AS400 / iSeries (MI400) mailing list
>> To post a message email: MI400-Zwy7GipZuJhWk0Htik3J/[email protected]
>> To subscribe, unsubscribe, or change list options,
>> visit: http://lists.midrange.com/mailman/listinfo/mi400
>> or email: MI400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
>> Before posting, please take a moment to review the archives
>> at http://archive.midrange.com/mi400.
>>
>>
> 
> _______________________________________________
> This is the MI Programming on the AS400 / iSeries (MI400) mailing list
> To post a message email: MI400-Zwy7GipZuJhWk0Htik3J/[email protected]
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/mi400
> or email: MI400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/mi400.
> 
> 
> _______________________________________________
> This is the MI Programming on the AS400 / iSeries (MI400) mailing list
> To post a message email: MI400-Zwy7GipZuJhWk0Htik3J/[email protected]
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/mi400
> or email: MI400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/mi400.
> 
> 
> 

_______________________________________________
This is the MI Programming on the AS400 / iSeries (MI400) mailing list
To post a message email: MI400-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/mi400
or email: MI400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mi400.