Ansicht
Dokumentation

04679 - Problem saving entire system

04679 - Problem saving entire system

Vendor Master (General Section)   Addresses (Business Address Services)  
This documentation is copyright by SAP AG.
SAP E-Book

Problem saving entire system

Hi All,

I see it as an Error is in OS400(IBM is calling it a limitation in V4R5 and
below)IBM also tells me that in V5R1 the problem does not exist any more -
so who is right ?

Error description and solution is as follows below:

Regards
Klaus


IBM Support Line
Technical Document

Document Number: 20132024
____________________________________________________________
Functional Area: Operating System
SubFunctional Area: Save/Restore
SubSubFunctional Area: General
____________________________________________________________
Product: Operating System/400 - OS/400 BASE (5716SS100); Operating
System/400 - OS/400 BASE (5763SS100); Operating System/400 - OS/400 BASE
(5769SS100)
Release: ALL

Classification: Public Use

Keywords:
____________________________________________________________
Document Title:Working a CPD373D Problem: User Profile Too Large to Save
Document Description:

Many ISeries 400 system users will never see a CPD373D error message;
others will encounter it occasionally. This message signals that the
system is unable to save a particular user profile.

Here is the full text of a CPD373D message. (To display the full text of
this or any message, use the DSPMSGD command or the Help key.)

Message. . . : User profile &1 too large to be saved.
Cause . . . . . : User profile &1 was not saved because its size has
exceeded the allowable limit of 16MB for a save operation.
Recovery . . : Do one of the following to reduce the size of the user
profile to less than 16MB and try the request again.
* Remove some private authorities
* Remove some objects owned by the user profile.

This message is misleading in that the inability to save a user profile is
not attributable to the number of objects a profile owns. The real problem
is that a profile can contain too many private authorities to objects owned
by other profiles. When the system saves a profile, it also saves the full
path names of objects for which the user profile has a private authority.
The path names are stored as a new object during the save. If this object
grows larger than 16MB, it becomes too large to be saved. This is a known
restriction. (It is anticipated that this issue will be addressed in a
future release.)

The maximum number of private authorities that can be saved in a user
profile is approximately 200,000. There is no exact figure because the
combined length of the full path names of the objects (as opposed to the
raw number of objects themselves) determines how much can be saved.

The print profile internals (PRTPRFINT) command, initially made available
with OS/400* V4R3, can provide insight into the number of entries,
including private authorities, already in the profile. (Private
authorities are one of four entry types; the others are owned object
entries, authorized object entries, and primary group entries.) PRTPRFINT
displays, as percentages, the overall number of entries along with the
number of individual entry types.

For example, a profile may contain 50 percent of the maximum number of
entries. This figure could include owned objects (20 percent of maximum),
private authorities (15 percent), authorized objects (15 percent), and
primary groups (0 percent). Because the maximum number of overall entries
allowed is 1,048,574, it can be assumed that profiles that display private
authorities at 15-19 percent of capacity are nearing the maximum number of
private authorities allowed (200,000/1,048,574 = 19 percent).

Circumventing the Problem

The most appropriate solution for reducing the number of private
authorities in user profiles is to define authorization lists across
multiple objects and give the user profile authority to the authorization
list. By doing this, private authorities are removed from the user
profiles. The advantage of this solution is that the user profile has only
one private authority entry for the authorization list. Thus, the
authorization list secures multiple objects, as opposed to each object
being secured by a private authority entry.

Here are the steps for performing this task on your system:


1 Analyze the authorities on your system to determine how many
authorization lists need to be created and which user profiles
need to 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 check for patterns of similar private
authorities across multiple objects and group them under one
authorization list.

Moreover, 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).

Once 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.



2 Create the necessary authorization lists by entering the
following on the OS/400 command line:

CRTAUTL AUTL(listname)



3 Add the user profile(s) to the authorization list. To add a user
name to the authorization list, enter 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, enter 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 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,
enter 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)
(Sysobjname 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.

-----Oprindelig meddelelse-----
Fra: Luc.VerheggenZg... [mailto:Luc.VerheggenZg...]
Sendt: 20. januar 2002 17:08
Til: Klaus Lindegaard (RWDK)
Emne: Re: SV: SV: Problem saving entire system




Klaus,

Just a guess: can you still do transports? Maybe the transportdirectory
contains
too many files....

Luc


|--------+------------------------------>
| | "Klaus Lindegaard |
| | (RWDK)" |
| | <klaus.lindegaardZro|
| | ckwool.dk> |
| | |
| | 18/01/2002 22:14 |
| | |
|--------+------------------------------>

>---------------------------------------------------------------------------
-|
|
|
| To: "'Jim Doll'" <JDOLLZp...>, "'SAP AS/400 Discussion
|
| Group' (E-mail)" <sap400Zm...>
|
| cc: (bcc: Luc Verheggen/BEGyproc/PlasterStone/Etex Group)
|
| Subject: SV: SV: Problem saving entire system
|

>---------------------------------------------------------------------------
-|





Durban Tours - Südafrika Safari

ABAP Short Reference   rdisp/max_wprun_time - Maximum work process run time  
This documentation is copyright by SAP AG.

Length: 12061 Date: 20240621 Time: 041348     sap01-206 ( 3 ms )