IBM Support

Message CPF5272 RC5 with a Database File

Troubleshooting


Problem

This document describes the actions to take when receiving message CPF5272 RC5 with a database file.
You may also see a SQL7062 message in QSYSOPR : *FILE HAS CONSUMED MORE THAN 90% OF THE LIMIT: 15400-MAXIMUM *MAX4GB INDEX SIZE

Resolving The Problem

This document describes the actions to take when receiving Message CPF5272 RC5 with a database file.

Message ID . . . :   CPF5272                                      
Message file . . :   QCPFMSG                                      
Library  . . . . :   QSYS                                        
                                                                           
Message . . . . :   Records not added to member &4.
Cause . . . . . :   The records were not added to member &4 file &2 in library &3, because the records require more storage than is available for the system, file, or owner of the file.
 
Recovery  . . . :   The storage limit has been exceeded for reason code &7.  The reason codes are:  

5 -- Object storage limit has been exceeded. An access path of member &8 file &9 in library &10 has reached its maximum size. Because of its internal structure, an IPL must be performed before additional entries may be added to the access path.                                                  
Note: The member mentioned in the Message may not be the member/file/library (&4/&2/&3) you need to check to see if it is as *MAX4GB.
For example, in the Recovery part of message for RC5, you will see the access path (logical file) that actually prevented the insert was member/file/library (&8/&9/&10)

Message CPF5272 RC5 is returned for a 4GB access path which has grown from < 10M to over 1GB on one IPL. In order for the access path to grow larger, an IPL is required. However, the user can change the 4GB capacity attribute path to 1TB and bypass the IPL.

You should check the Access Path Size (ACCPTHSIZ parameter) associated with the file. For additional information refer to TechNote Determining if You Have Access Paths at *MAX4GB 
To resolve the problem, you should do the following:
1. If the access path size is *MAX4GB and if the file is a logical file, change the size to *MAX1TB using the Change Logical File command (CHGLF). If the file is a physical file, use the Change Physical File command (CHGPF) using the ACCPTHSIZ parameter.

There are multiple reasons why 1TB is much better than the 4GB style of index--better concurrency, better performance, and so on. This is our normal recommendation.
2. IPL the box to allow the access path to grow to a larger size. Do this if there is a specific reason to keep the access path at MAX4GB.
3. Use the Change Physical File command (CHGPF) or Change Logical File command (CHGLF) using the ACCPTHSIZ to MAX1TB and then later use the same command to change back to MAX4GB. This is in case you need to keep the access path at MAX4GB and need to avoid an IPL.
Note: If SMP (Product Option 26) is installed, it is recommended that you run the access path rebuilds one at a time. If multiple rebuilds are running simultaneously, resource contention can occur. If SMP is not installed or set to *NONE, the number of SBMJOB commands must be equal to or less than the number of processors unless there there is other workload going on.
If you see a CPF3210 "File &1 in library &2 not correct type." when you do a CHGPF with ACCPTHSIZ parameter you may have a System/36 file.
In that situation you cannot CHGPF to resolve the issue. 
You will need to recreate the System/36 file, copying out the records first and copying back after the System/36 file has been created. 
Your DSPFD will now show that 'Access path size' is *MAX1TB.
 

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"ARM Category":[{"code":"a8m0z0000001i6QAAQ","label":"IBM i Db2->Index \/ Access Path \/ Logical file"}],"ARM Case Number":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Version(s)","Line of Business":{"code":"LOB57","label":"Power"}}]

Historical Number

N1018772

Document Information

Modified date:
28 January 2021

UID

nas8N1018772