Tweet
After reviewing our QAUDJRN journal we noticed a "GR" entry is written every time our application invokes QsyCheckUserFunctionUsage API. How can we stop this? Our application runs slower after we added QsyCheckUserFunctionUsage API calls. Will removing the "GR"-writes improve our performance?
-
-
audit journal type
Hello Gene, It seems that the 'GR' entries are triggered by the QAUDLVL setting of the *AUTFAIL logging (table 111, security reference V4R5). The performance hit resulting from the journal-entry write itself is in my experience very low, although the cost of gathering the entry-specific information might vary. To reduce the journal-entry writing related impact on performance, the system value QAUDFRCLVL (force auditing data) could - if it isn't already - be set to *SYS - allowing the system to buffer the entries between writes (but resulting in a possible loss of the buffered entries in case of a system crash). - My best bet would be the other functions performed by the QsyCheckUserFunctionUsage API, but temporarily removing - if possible - the *AUTFAIL setting might give you a better answer as to how the 'GR'-entries affect performance. Best regards, Carsten Flensburg -
audit journal type
Thanks Carsten, however Security Reference table 111 is incorrect. Our security auditing level is (*SECURITY *DELETE *CREATE *OBJMGT *SAVRST), our user profile auditing values are either *NONE or (*CREATE *DELETE), and we're still getting boatloads of "GR" journal entries for every QsyCheckUserFunctionUsage API invocation. I'm curious why the QsyCheckUserFunctionUsage API "GR" entry omits showing whether a user was allowed or denied access to a function. All it shows is that a QsyCheckUserFunctionUsage API invocation occured. So what? I like the cute "weebles wobble but they don't fall down" icons in Operations Navigator -> Application Administration -> Host Applications, where I drag users into a "usage allowed" list below a user function name, but each user-drag creates a "GR" journal entry. I found the system stores the user function authorities as OS/400 private and public authorities over *FCNUL objects, so I replaced our QsyCheckUserFunctionUsage API calls with MATAU MI instructions and saved 3 seconds start-up time in our application.Comment
-
audit journal type
Gene, Thanks Carsten, however Security Reference table 111 is incorrect. Our security auditing level is (*SECURITY *DELETE *CREATE *OBJMGT *SAVRST), our user profile auditing values are either *NONE or (*CREATE *DELETE), and we're still getting boatloads of "GR" journal entries for every QsyCheckUserFunctionUsage API invocation. I did wonder why IBM had put this type of entry in the *AUTFAIL category - after all many of the actions registered does not have anything to do with authority failure, maybe *SECURITY would be the right place to put those. I'm curious why the QsyCheckUserFunctionUsage API "GR" entry omits showing whether a user was allowed or denied access to a function. I don't know if I should rely on the Sec Ref on this one, but appendix F describes the layout of the various entry types and claims that the QASYGRJ4 record format in position 243 - Field 1 data - for entry type F holds one of 6 values:*REGISTER: Function has been registered *REREGISTER: Function has been updated *DEREGISTER: Function has been de-registered *CHGUSAGE: Function usage information has changed *CHKUSAGE: Function usage was checked for a user and the check passed *USAGEFAILURE: Function usage was checked for a user and the check failed
The two last ones should - if the manual is to be trusted - let you decide how the check ended. I found the system stores the user function authorities as OS/400 private and public authorities over *FCNUL objects, so I replaced our QsyCheckUserFunctionUsage API calls with MATAU MI instructions and saved 3 seconds start-up time in our application. I know that MI is fast, but I think that a difference of 3 seconds indicates that the QsyCheckUserFunctionUsage implementation is suffering from problems of a kind almost preventing the use of this function in most applications - you sure need a very good reason for slowing down response time that much. Best regards, CarstenComment
-
audit journal type
Aha, *CHKUSAGE and *USAGEFAILURE are mutually exclusive in the journal, I stand corrected. Thanks Carsten.Comment
Comment