Re: setsppfp crashes with MCH6801

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 <thomas.raddatz@xxxxxxxxxxx> 
Sent by: mi400-bounces@xxxxxxxxxxxx
05/09/2006 10:55 AM
Please respond to
MI Programming on the AS400 / iSeries <mi400@xxxxxxxxxxxx>


To
MI Programming on the AS400 / iSeries <mi400@xxxxxxxxxxxx>
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@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/mi400
> or email: MI400-request@xxxxxxxxxxxx
> 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@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/mi400
or email: MI400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mi400.