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 (http://www-01.ibm.com/support/docview.wss?uid=nas8N1022161), 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.

Detect corrupted indexes so they can be rebuilt.