IBM Support

SAVSECDTA is Taking a Long Time

Troubleshooting


Problem

This document explains that SAVSECDTA performance problems are usually due to the percentage of private authorities owned by a user profile.

Resolving The Problem

SAVSECDTA saves the user profiles and their authorities. This step in a backup will generally take between 5 and 30 minutes. If this step has increased significantly, it can be due to the number of objects or private authorities that have increased.

Very large percentage profiles will slow down the SAVSECDTA.

Note: If a user profile is too large, a message CPD373D error is encountered and the user profile is not saved; therefore, the SAVSECDTA will not take long.

A summary of profile sizes is shown below:
 
Maximum Number of Entries Maximum Number of Entries / IASP
V4R3 1 million Not applicable
V4R4, V4R5 1 million or 5 million (dependent upon format) Not applicable
V5R1 5 million 5 million
V5R2 to V5R4 10 million 10 million
V6R1 50 million 50 million
V7R1 50 million 50 million
V7R2 50 million 50 million
V7R3 50 million
50 million
V7R4 50 million 50 million
V7R5 200 million 200 million

To find large percentage user profiles, you should issue the following command:

PRTPRFINT SELECT(*PCTFULL) PCTFULL(1.00)

If you are at V6R1 or later, to find large percentage user profiles, you should issue the following command:

PRTPRFINT SELECT(*PCTFULL) PCTFULL(.20)

Issue the WRKJOB command, Option 4, and select 5=Display for the QPSECPPI spooled file. The output will look similar to the following:
 
                                               User Profile Internals                      
 5722SS1 V5R4M0  060210                                                                      
  Select by  . . . . . . . . . . :   *PCTFULL
  Percentage full  . . . . . . . :     1.00

                      Percent of    Private     Percent of     Percent of    
  User       Percent  Owned Object  Authority   Authorized     Primary Group  
  Profile    Full     Entries       Entries     User Entries   Entries  
  BRIAN      11.01      10.97        4.08          0.01          0.00  
  DANIELLE    7.08       6.5        13.28          0.25          0.00      
  DESTINY    12.27      12.27        7.31          0.00          0.00      
     * * * * *   E N D   O F   L I S T I N G   * * * * *

Any profile that has private authority entries over 1.00 percent or .20 percent (V6R1 and above) is potentially slowing down the SAVSECDTA. The number of objects a profile owns is not relevant to SAVSECDTA performance. Therefore, profiles that are large due to owning many objects (Percent of Owned Object Entries), will not impact the performance of SAVSECDTA. The SAVSECDTA performance problem is almost always due to the Percent of Private Authorities Entries being large. In particular, profiles that have many private authorities on IFS objects will be impacted the most.

Resolution

The resolution for a large percentage of private authority entries is to either create a group profile or an authorization list.

Group Profiles

If multiple users are privately authorized to an object, those authorities can be reduced by grouping the profiles and authorizing the group rather than each profile individually. This will not eliminate the save time required for the private authorities; however, it will prevent the same authorities from being saved for multiple profiles. This reduce the time for SAVSECDTA, especially if several profiles can be combined into a group.

To create a group profile, issue the CRTUSRPRF USRPRF(group_profile_name) command. After a profile is created, you can change individual profiles to be a part of that group profile with the following command:

CHGUSRPRF USRPRF(user_profile_name) GRPPRF(group_profile_name)

Once the group profile is created and the users are in the group, the authorities will not be automatically shifted to the group. First, authorize the new group to all objects that the members of the group need. Use GRTOBJAUT to grant this new authority.

After the users are in the group, and the group has all necessary authority, the private authorities for the users can be cleaned up. Use the RVKOBJAUT command to remove the private users from the necessary objects. Until the private authorities are removed, SAVSECDTA time will not be reduced.

To completely eliminate the need for private authorities, an authorization list is required.

Authorization Lists

Authorization lists are used to give a set of users specific authorities to an object or a set of objects. Each user has the authorities to all of the objects secured by the authorization list. When an authorization list is granted authority to an object, the users on the list get authority to the object. The authorities the users receive are those specified for them in the authorization list.

If a user is granted private authority to a million objects, that user has a million private authorities. However, if the million objects were secured by the same authorization list and a user was on that authorization list, they would only have the equivalent of one private authority. This is why authorization lists are the most efficient when dealing with SAVSECDTA performance issues.

Use the following commands to create authorization lists, add authorities, add the user profiles to the authorization list, secure the objects with the authorization list, and remove the user profiles private authorities to the objects:
1. Analyze the authorities on your system to determine how many authorization lists must be created and which user profiles must be on each of the lists. Various tools can help users plan authorization lists.

The Print Private Authorities (PRTPVTAUT) command allows users to print reports listing all the private authorities for objects of a specified type in a specified library or folder. The report also lists the users that are authorized to the object. With this information, you can look for patterns of similar private authorities across multiple objects and group them under one authorization list.

It can be determined if private authorities are necessary. For example, a user with a private authority equivalent to *PUBLIC can have that authority removed. The PRTPVTAUT command should be run against the main object types (for example, *FILE, *PGM, and *CMD) in the main application libraries. Here is an example of the PRTPVTAUT command:

PRTPVTAUT OBJTYPE(*FILE) LIB(library)

The Display User Profile (DSPUSRPRF) command can be used to list the private authorities that an individual user profile has to documents and folders and objects in libraries. This is a way to determine what authority the user profile should have on the authorization lists that are created. You can also determine if the user needs those private authorities. For example, if the user profile has *ALLOBJ special authority, private authorities to objects are not needed. Here is an example of the DSPUSRPRF command:

DSPUSRPRF USRPRF(username) TYPE(*OBJAUT) OUTPUT(*OUTFILE) OUTFILE(library/filename)

The QSYLOBJA API can be used to list the private authorities that an individual user profile has to documents and folders and objects in libraries (using formats OBJA0100, OBJA0200, or OBJA0300) or objects in directories (using formats OBJA0110, OBJA0210, or OBJA0310).

After a group of objects containing a set of users with the same private authorities is found, an authorization list can be created, and the users provided with authority to the group of objects. The users can be added to the authorization list and the objects can be secured by the authorization lists. This allows the private authorities to be removed from the object.

Note: There is a limit to the number of objects that can be associated with one authorization list. At R530 and R540, the limit is 2,097,070.
2. Create the necessary authorization lists by typing the following on the operating system command line:

CRTAUTL AUTL(listname)
3. Add the user profile(s) to the authorization list. To add a user name to the authorization list, type the following:

ADDAUTLE AUTL(listname) USER(username) AUT(*AUTHORITY)

Note that *AUTHORITY can be any authority selected for the user. The USER parameter accepts multiple names. The AUTL parameter accepts generic names.
4. Secure the appropriate object(s) with the appropriate authorization list. To change the object authority for an object, type one of the following commands:
o For objects in libraries:

GRTOBJAUT OBJ(library/object) OBJTYPE(*type) AUTL(listname)
or
EDTOBJAUT OBJ(library/object) OBJTYPE(*type)

(Library, object, and type from the DSPUSRPRF command)
o For folders and documents:

CHGDLOAUT DLO(*SYSOBJNAM) AUTL(listname) SYSOBJNAM(sysobjname)
or
EDTDLOAUT DLO(*SYSOBJNAM) SYSOBJNAM(sysobjname)

(SYSOBJNAME from the DSPUSRPRF command)
o For objects in directories:

CHGAUT OBJ(‘/objectname’) AUTL(listname)
or
WRKAUT OBJ('/objectname')

(Objectname from QSYLOBJA output)

Note: For the OBJ parameter on the WRKAUT OBJ(‘/objectname’) and CHGAUT commands, the object name from QSYLOBJA will be in UCS2, or Unicode, and it must be converted to the job CCSID before issuing the CHGAUT or WRKAUT command.
The GRTOBJAUT, CHGDLOAUT, and CHGAUT commands allow *generic names or the use of *ALL so that all objects within a library, folder, or directory can be changed.
5. For each object secured with an authorization list, the private authorities for the user profiles on the authorization list should be removed. To remove the private authority to an object, type one of the following commands:
 
o For objects in libraries:

RVKOBJAUT OBJ(library/object) OBJTYPE(*type) USER(username) AUT(*ALL)
or
EDTOBJAUT OBJ(library/object) OBJTYPE(*type)

(Library, object, and type from the DSPUSRPRF command)
o For folders and documents:

RMVDLOAUT DLO(*SYSOBJNAM) USER((username)) SYSOBJNAM(sysobjname)
or
EDTDLOAUT DLO(*SYSOBJNAM) SYSOBJNAM(sysobjname)

(SYSOBJNAM from the DSPUSRPRF command)
o For objects in directories:

CHGAUT OBJ(‘/objectname’) USER(username) DTAAUT(*NONE) OBJAUT(*NONE)
or
WRKAUT OBJ('/objectname')
6. The create commands can be set on your system so that new objects are secured by an authorization list. Using the Change Library (CHGLIB) command, the CRTAUT parameter for a library can be changed and an authorization list name specified so that any objects created into the library are secured by the specified authorization list. Using the Change Command Default (CHGCMDDFT) command, the AUT parameter for the Create Folder (CRTFLR) command can be changed and an authorization list name specified so that any new folders are secured by the specified authorization list.
Controlling the use of private authorities makes it easier to manage system security, and eliminating unnecessary private authorities can enhance system performance.

Useful Tools

There is a CHGAUTALL tool that can be very useful in changing private authorities of Integrated File System objects. This tool is described in technote document N1019580, Integrated File System Tools: DEL, DELTREE, CMDALL, CHGAUTALL, CHGOWNALL, QRYIFSLIB, DLTIFSF, RNMIFSF.

There is a tool to list private authorities that can be very useful in obtaining a list of all the objects for which a user profile has private authority. This tool is described in technote N1019215, Tool to List Private Authorities.

Refer to technote N10121449, Removing Private Authorities and Replacing them with Authorization List using a program, for a sample program that will Remove Private Authorities and Replace them with Authorization List.

[{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Platform":[{"code":"PF012","label":"IBM i"}],"Version":"7.1.0"}]

Historical Number

485601472

Document Information

Modified date:
16 September 2022

UID

nas8N1018753