MCH2804: Tried to go larger than storage limit for object

What it means

Many objects on IBM i have internal storage that grows as they are used, and each has a limit. When an operation needs the object to grow past that limit, the machine refuses and sends MCH2804. The message names the object. The fix depends entirely on what that object is.

The object most often named is a user profile. A user profile keeps internal entries for every object it owns and for the private authorities it holds. IBM's support documents explain that a profile that owns a very large number of objects, holds many private authorities, or both, can reach the size limit for those entries. After that, creating an object owned by that profile, or granting it another private authority, fails.

IBM's Security Reference advises against having one profile own all or most objects on a system for this reason. This isn't limited to IBM-supplied profiles. Any application owner profile that owns everything can hit it.

Common causes

• A user profile owns too many objects. A single application owner profile, or a profile that every job runs under, creates objects for years until the profile is full.
• A user profile has too many private authorities, for example one granted to each of thousands of objects one by one.
• Both of the above together on the same profile.
• Another object reached its internal limit. The object named in the message tells you which one, and IBM support has documents for specific object types.

How to find the problem

1. Run DSPJOBLOG and press F1 on MCH2804. Note the object named in the message, then look at the message just after it to see which command or operation failed.
2. If the object is a user profile, list what it owns with DSPUSRPRF USRPRF(APPOWNER) TYPE(*OBJOWN) OUTPUT(*PRINT) and look at the count.
3. List the profile's private authorities with DSPUSRPRF USRPRF(APPOWNER) TYPE(*OBJAUT) to see how many there are and which libraries they cover.
4. If the object isn't a profile, search IBM support for MCH2804 together with the object type, since the limits and remedies differ by object.

How to fix it

• Spread ownership. Create one or more new owner profiles and move objects to them with CHGOBJOWN. Group applications or libraries by owner so no profile owns everything.
• Cut private authorities. Put users in group profiles and grant authority to the group, using supplemental groups where users need more than one.
• Use authorization lists instead of granting private authority object by object. One authorization list entry can secure many objects.
• Delete objects the profile owns that nobody needs, such as old work files or objects left over from retired applications.
• Follow IBM's support documents on user profile size limits for the detailed steps on your release.

DSPMSGD MSGID(MCH2804) MSGF(QSYS/QCPFMSG)

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s documentation for your IBM i release.