Profiles contain attributes such as initial program, initial menu, output queue, etc., but the *USRPRF object also contains other information. Specifically, *USRPRF objects contain an entry for every object the profile owns, an entry for every private authority granted to it, an entry for every private authority granted to one of its owned objects, and an entry for every object for which it’s been made the primary group profile. There is a limit to the size of the user profile object, and it’s these entries that contribute to that size. Back in the late Version 4 and Version 5 releases, it was fairly easy to reach the limit, especially if one profile owned most of the objects on the system and it was one of the larger iSeries systems. Running the PRTPRFINT command allowed you to monitor how full profiles were getting and use that to avoid situations where applications failed because the application profile couldn’t own more objects. Today, the maximum size of the user profile object has been increased so much that it’s very difficult to reach the limit (although it’s still possible). Even so, the PRTPRFINT still yields interesting information, especially when you’re trying to determine why a SAVSECDTA operation is taking a long time.
When prompting the PRTPRFINT command, you can specify that you want all profiles or only profiles that are greater than a specific percentage full. I usually run the report looking for profiles greater than 2% full. Yes, just 2%. Sometimes, you’ll get a report with lots of profiles just over 2% full, but usually, you’ll see that 2–5 profiles are the culprits; those are profiles that have a large number of private authority entries, typically 5–10% full of private authority entries. Often, they’re either administrator profiles or service accounts.
Now that you’ve identified the profiles, you have to determine what objects they’ve been authorized to. Enter the Work with Objects by Private Auth (WRKOBJPVT) command. This command lists all of the objects, including IFS objects, to which the user has been granted a private authority. About 95% of the time, the issue will be that the profile has private authorities to hundreds if not thousands of IFS objects. Now the trick is to determine how that’s happening and whether the user even needs authority to the objects. If they do, then you need to determine how they’re going to continue to have access but via some means other than a private authority. What you’ll often find is that subdirectories have been created by a different administrator than the directory, and the original creator now has a private authority to the subdirectories and everything in them. In this case, the way to correct the issue is to remove the unnecessary private authorities from the subdirectory where the objects are being created. The objects will no longer be created with the excess private authorities.
Let’s look at an example. You’ve found via analyzing the output of PRTPVTAUT that profiles Alex, Scott, and Geoffrey are the “fullest” profiles on the system. Running the WRKPVTAUT commands against the Alex and Scott profiles shows that they have a private authority to each invoice stored in the /Company/Product/AR_App directory. How is this happening? A closer look at the ownership of these directories reveals that Alex originally created the /Company directory, but Scott created the /Company/Product directory. Because subdirectories inherit the authority from its parent, the system grants Alex a private authority to the /Company/Product directory. Later, the AR_App directory was created to hold archived invoices. That directory was created by Geoffrey, so now both Alex and Scott have a private authority to the /Company/Product/AR_App directory. Objects (the invoices) are written to this directory via a nightly scheduled job running as Ted. Whenever a new invoice is created, the system grants Alex, Scott, and Geoffrey a private authority to the stream file (*STMF) storing the invoice.
Now that you’ve found the source of the issue, how do you resolve it? The easiest way to resolve this is to make Ted the owner of the /Company/Product/AR_App directory, making sure to take the option to revoke the current owner’s (in this case, Geoffrey’s) authority, as well as removing the private authorities granted to Alex and Scott. New invoices will only have Ted’s owner authority and *PUBLIC authority, eliminating the unnecessary private authorities.
Some organizations have a similar application and will keep a rolling 60 or 90 days’ worth of information. If that’s the case, you may choose to simply let the invoices with the extra private authorities age off the system. However, if this is a true archive and the number is continuing to increase, you may want to remove the excess private authorities by running the Change Authority (CHGAUT) command. The following removes the private authorities granted to Alex to both /Company/Product/AR_App directory as well as all objects in the directory.
I’ve seen several variations of this issue, but this discovery technique has allowed me to resolve them all.
The authority granted to the owner of an object does not count as a private authority! Rather, it’s an ownership entry in the *USRPRF; therefore, you shouldn’t remove owners’ authority. In fact, removing owners’ authority to IFS objects can cause subsequent objects to be created without the owner having Object Authorities, causing some hard-to-debug operational issues (strange but true.) |