|
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 ViningThomas Raddatz <thomas.raddatz@xxxxxxxxxxx> Sent by: mi400-bounces@xxxxxxxxxxxx05/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 MCH6801Thanks 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 typeis 1 = Object domain violation.Both LPARS (production and test) are at security level 30. As far as I know the production LPAR isDBCS 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.
As an Amazon Associate we earn from qualifying purchases.
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.