Authorization Lists: New Nav – Object Authorities

To manage authorization lists in New Nav, click on the padlock icon and choose Authorization Lists as shown in Figure 7.4. You’ll see that all permissions for all authorization lists are displayed. That’s because what IBM has done is run the QSYS2.AUTHORIZATION_LIST_USER_INFO for all autls and displayed the results. To be honest, this isn’t all that helpful. Yes, you can narrow down the results by specifying a particular authorization list, but I find this view and the output from QSYS2.AUTHORIZATION_LIST_USER_INFO to be no better than running DSPAUTL from a command line. But it’s worse in one way because I can run Edit Authorization List (EDTAUTL) and change the permissions. One handy aspect of this view is that you can highlight one entry and either right-click or choose Actions and get the objects secured by the list. Again, all that’s been done is to run the QSYS2.AUTHORZATION_LIST_INFO service for a specific autl. Hopefully, at some point in the future, IBM will add more functionality to this authorization list category, such as the ability to modify permissions.

Figure 7.4: Manage authorization lists in New Nav by clicking on the padlock icon.

Object Statistics: Objects in Libraries

While it may not be obvious, the QSYS2.OBJECT_STATISTICS table function can help manage your security implementation. Building from the example I provided in chapter 5, where I discussed the inability to delete a profile due to its owning objects, we can use OBJECT_STATISTICS to perform more investigation. Rather than just reassigning those owned objects to another profile, I’d rather identify objects that haven’t been used in a while and remove them from the system.

The OBJECT_STATISTICS table function is the equivalent of Display Object Description (DSPOBJD). But unlike DSPOBJD, I can customize the SQL to give me information on objects in libraries that are owned by a specific profile. The following example lists the objects owned by profile CAROL.

Then, I can add a WHERE clause that will allow me to see objects in libraries that have not been used within the last year and would, therefore, be a candidate for deletion. (Of course, if your organization has a different data-retention timeframe, you can alter the SQL timestamp math to match that.)

Note If all you wish to see is a simple list of the objects owned by a user, a much better-performing option is to use QSYS2.OBJECT_OWNERSHIP.

Object Statistics: Objects in Directories

For IFS object information, you’ll have to use the QSYS2.IFS_OBJECT_STATISTICS table function. The following example will list the objects owned by CAROL in the directory you specify. I should have warned you that the previous example may run awhile when you leave the first parameter (the library parameter) as *ALL. In the following example, if you specify the /root directory for the path name and you store many objects in the IFS as some organizations do, you’ll have to be prepared for this to run a long time! Therefore, you may want to scope this selection down to a directory where you know the profile owns objects.

And just like objects in libraries, timestamp arithmetic works for the IFS objects as well: