Object Statistics: Last_used_object Field – Object Authorities
Note
Be careful when you’re evaluating *DIR objects. The last-used date isn’t updated. In other words, you must evaluate the objects in the directory to discover the correct last-used date. In fact, this is where the field last_used_object recently added to both QSYS2.OBJECT_STATISTICS and QSYS2.IFS_OBJECT_STATISTICS table functions is handy. It provides an indication of whether the object’s last-used date is updated. A value of YES means that the last-used date is updated whenever the object is used. NO means it’s not, so you shouldn’t use the last-used date to determine whether you can delete the object based on usage.
Tech Note
As of IBM i 7.5, information about *USRPRF objects will not be returned by interfaces such as QSYS2.OBJECT_STATISTICS unless the profile running the service has some authority (not *EXCLUDE) to the profile.
Protect Information from Appearing in the Plan Cache and Database Monitors
While the tools IBM provides for database analysis are invaluable for tasks such as performance analysis, one problem is that they may contain data that people performing the analysis shouldn’t be allowed to see. To protect sensitive information, you can use the sysproc.set_column_attribute procedure to set the column in a database file so that the contents won’t appear in either a database monitor or plan cache. Be aware that running this takes action! It’s not an “info only” service. Running the following will set the CCNBR column in the Orders file in the LIB1 library so that its contents will not be listed in the plan cache and database monitors. Rather, the variable values will be shown as *SECURE.
You can use qsys2.syscolumns2 to see which columns have set this attribute.
Let’s look at some of the ways the audit journal can help you.
There’s a variety of ways to use the audit journal in the context of object authorities, the most obvious being the Authority Failure (AF) entries. I used the AF entries in an earlier chapter to look for issues prior to moving to QSECURITY level 40. But in this context, you’d likely be using the AF entry to determine the actual object the process failed on. Many of you are probably saying, “I just look in the joblog for the object name. Why would I want or need to look in the audit journal?” Good question! Many times, the object name in the joblog is correct. But I’ve had cases where there had been an authority failure, but the process kept running and the authority failure appearing in the joblog was three to four steps after the actual failure. So attempting to solve the authority failure for the object stated in the joblog was futile. That’s why, as a rule, when I’m debugging an authority failure, I’m going to look in the audit journal to verify that I’m debugging the right issue.