Skip to Main Content
IBM Power Ideas Portal

This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Workspace IBM i
Categories Db2 for i
Created by Guest
Created on Mar 13, 2018

Command to validate indexes

I am filing this RFE in response to the listed PMR at the advice of the IBM staff working on that issue.
We recently had a case where a specific record in a table somehow did not update all related indexes using the updated field as a key. This left the row unable to be found when querying using the new value, because the key did not match. The problem was in the access path so it impacted both SQL and accessing via RPG. Rebuilding the access path using CHGLF FRCRBDAP(*YES) does key the row properly, but there was no way to detect this problem and with 10,000s of indexes on our system, running this on all indexes on a periodic basis is impractical.
Support directed us to the Index check tool (, but this tool does not work when the index uses a sort sequence. We always use a shared-weight sort sequence to allow case insensitive matching on character fields, so this makes the tool useless for the majority of our indexes.
While we can accept that the cause of this issue likely cannot be determined (we estimate the index keys have been wrong for over two years, but since we do not journal logical files there is no way to know for certain), we cannot accept that it is impossible for IBM to construct a tool which verifies all index keys match the expected values for their row data.
I have built a rudimentary tool in RPG for brute-force testing indexes to detect keying issues, but this does not work with tables containing LOB values. I assume IBM, with full access to closed APIs and the physical index structures, could build a much more efficient implementation using lower-level code which would handle indexes using sort sequences, even for tables containing LOB values.
The concept for the tool would be to walk through the entire index tree. At each node, it would read the record from the table matching the RRN of that node, calculate the key value using the sort sequence, and compare that to the stored key value. If the key value does not match, an error would be indicated on the resulting report, with the option to force an access rebuild at the end of the process if any errors were detected.
I understand that this tool would be a long running process, taking hours for large indexes; we would rather have to run this every weekend against all indexes and know that our indexes are correct, rather than having indexes that “miss” expected records.

Use Case:

Detect corrupted indexes so they can be rebuilt.

Idea priority High
  • Guest
    Nov 22, 2020

    IBM does not intend to provide the requested solution at this time, so it is being closed.

    In the past several years, some changes have been made to the index maintenance code to prevent indexes from being corrupted by detecting and correcting problems before they affect the index. This is believed to be the source of the problem that generated this RFE request.

    The cost to implement a new tool to validate indexes is high, and would be very performance intensive since it would need to look at every key and every row. The current service tool is generally adequate and IBM does not advise anyone to regularly and proactively run the tool, The content of the index should be trusted to contain the appropriate data.

  • Guest
    Aug 21, 2018

    The CEAC has reviewed this requirement and recommends that IBM view this as a high priority requirement that is important to be addressed.

    Background: The COMMON Europe Advisory Council (CEAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CEAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community and has therefore reviewed your RFE.

    For more information about CEAC, see

    Therese Eaton - CEAC Program Manager