Don't cancel or stop running the job that is saving your IBM i security data. Instead, read this article for four steps you can take to reduce the time.

By Carol Woodbury

Saving your IBM i security data is a critical part of being able to recover your system, but when it starts to take too long, you may be tempted to stop this process. This article helps with understanding the process and determining what might be causing the increased time. It also provides you with tips for reducing the overall time.

What's Saved When You Run Save Security Data (SAVSECDTA)?

To understand how to reduce the time to run SAVSECDTA, you first need to understand what's saved during this process. When running SAVSECDTA, all user profiles, authorization lists, and private authorities are saved. How often you run SAVSECDTA depends on how often you're creating, changing, or deleting profiles; granting or revoking private authorities, or modifying authorization lists. Unless you have a record of every addition or change you've made since the last time you ran SAVSECDTA, you will need to run SAVSECDTA often - probably nightly. Early on, running SAVSECDTA required the system to be in restricted state, but that requirement was lifted some time ago. For many organizations, running SAVSECDTA nightly makes the most sense...that is, until it starts to take longer and longer and eventually gets to the point it hasn't finished when you come in in the morning. That was the plight of one of our clients when they asked for our help. Let's look at four steps for reducing your SAVSECDTA time.

Step 1: Delete Unused Profiles

I probably sound like a broken record on the topic of removing inactive profiles, but this is yet another reason for removing unused or - stale - profiles from your system rather than just setting them to status of *DISABLED. Unless the application you're running has a hard requirement that all profiles (even inactive ones) remain on the system for historical reporting purposes, there is no reason to keep old profiles. Those old profiles pose a security risk. The risk is that they will be re-enabled and used. And because the original person assigned to any given profile is either no longer with the organization or doesn't require access to the system, the profile's use will go unnoticed.

Step 2: Delete Unused Authorization Lists

Since the SAVSECDTA process saves authorization lists, like unused profiles, you'll want to delete unused authorization lists. You might be tempted to delete an authorization list if it doesn't secure any objects, but I caution you not to do that. Yes, make that part of your analysis, but some applications use authorization lists to control access to a function. In fact, the operating system does this with the QPWFSERVER authorization list. (Authority to this list allows the user to see the QSYS.LIB file system in Windows Explorer and Navigator for i interfaces.) Prior to deleting an authorization list, first determine if it's being used in this manner.

Step 3: Consider Using Authorization Lists

If you have granted the same private authority to many objects, consider attaching an authorization list to the objects, granting the appropriate private authority to the authorization list, and removing the private authorities granted to the individual objects. For example, perhaps you've granted GRPPGMR *USE authority and AUTHDEBUG *CHANGE authority to all physical files in your application libraries. This would amount to the system having to save two private authorities for every database member plus one for the cursor multiplied by the number of files multiplied by 2 (for the authority to GRPPGMR and AUTHDEBUG.) That's a lot of private authorities being saved! Contrast that with using authorization lists. That way, the system is saving only two private authorities: the authorities (GRPPGMR and AUTHDEBUG) have been granted to the authorization list. Depending on how many files and whether the files are multi-member, this could be a huge difference.

Step 4: Find and Remove Unnecessary Private Authorities

Next ,we have the scenario that our clients found themselves in - a growing number of private authorities. They could tell by using performance tools what part of the SAVSECDTA was taking the longest. But they had no idea how to determine to what objects the authorities had been granted. To determine this, they ran Print Profile Internals (PRTPRFINT). This command lists how  - full - a profile is. Let me explain what I mean by that.

Profiles contain attributes such as initial program, initial menu, output queue, etc., but the *USRPRF object also contains other information. Specifically, *USRPRF contains an entry for every object the profile owns, an entry for every private authority, 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-Version 5 releases, it was fairly easy to reach the limit, especially if one profile owned most of the objects 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, while still possible, the maximum size of the user profile object has been increased so much that it's hard to reach the limit. 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 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.

We've seen several variations of this issue, and although it takes a bit of detective work, with some perseverance you can find and fix the issue(s).

The Value of Saving Time

What I never stated but I hope is understood is that reducing the time for SAVSECDTA to run also reduces the time it will take should you ever have to restore your system. It should go without saying that you don't want to have to waste your time restoring unneeded profiles, authorization lists, or authorities when all you want to do is get your organization back up and running.

Hopefully, you've found these tips helpful for eliminating unnecessary processing during both your save and restore processes.