MIDRANGE dot COM Mailing List Archive



Home » MI400 » May 2006

Re: setsppfp crashes with MCH6801



fixed

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


_______________________________________________
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.









Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact