The full error in the NAV.LOG file may look like:
[2013-01-29T13:32:08.793000]; Table customer has no field with length 10 at offset 0
[2013-01-29T13:32:08.851000]; [A00D] Failed to open table test:customer


This error message means _exactly_ what it indicates.
The AIS ADD-RMS driver was looking for a user declared field which would match the actual RMS (FDL) key index segment for the file being opened.

This error typically happens when the file is converted with an updated FDL to add a physical key, without the metadata being changed correspondingly.

The straightforward solution is to make the metadata match the actual file making sure that each segment in the key has a corresponding field. (RMS keys often have just 1 segment, but may have up to 8 disjoint segments.
However this my introduce additional fields and/or groups which may impact existing application when they perform operations such as SELECT * FROM.

There is an alternative to providing a corrected field layout.
The AIS ADD-RMS driver wants/needs to understand the index structure to help the Query Processor make the right choices. It needs the information to be able to choose to use an index, or not.
IF the metadata for the table does NOT provide a <KEYS> section, or an empty one like <KEYS\>, THEN the ADD-RMS drive will analyze the existing indexed, matching them to fields.
IF the metadata for the table DOES provide a <KEYS> section, then only those keys will be considered and no field matching will be executed.

Therefor the alternative solution is to explicitly provide a <KEYS> section in the metadata.
Ideally that keys section would fully match all the existing RMS keys, but one can omit a troublesome key or indeed provide a dummy key not matching an actual key, only providing an actual field.
Of course one tries to provide as many real keys/indexed definitions as possible, in order to give the Query Processor a fighting chance to avoid full tablescan.

Example:
Code:
$ nav_util export table navdemo customer customer.xml
$ edit customer.xml ... remove <keys> section
$ nav_util import test CUSTOMER.XML
$ type customer_test.sql
select c_custkey, c_name from customer limit to 3 rows;
$ nav_util execute test customer_test.sql
:
: < works fine>
:
$ ! Issue a convert with a bogus FDL indicatign a key NOT matching a field
$ convert/fdl="fil; org ind; key 0; seg0_l 10" navroot:[DEMO]customer.INX -
   navroot:[DEMO]customer.INX
$ nav_util execute test customer_test.sql
[A00D] Failed to open table test:customer
$ edit customer.xml ...  Add the following section after </fields> before </table>

                <keys>
                        <key name='cindex' nRows='0'>
                                <segments>
                                        <segment name='c_comment'/>
                                </segments>
                        </key>
                </keys>
$ ! Note how the added segment does NOT correspond with the actual key
$ nav_util import test CUSTOMER.XML
$ nav_util execute test customer_test.sql
:
: < works fine again, thanks to the 'while lie', but only sequential scans can/will be done>
:


Hope this helps,
Hein van den Heuvel
Note 1) The "nav_util update" command can and will create a complete metadata definition for all the keys, with exact or estimate statistics.

Note 2) That "nav_util update" may fail with a related error message "nvITDP_DescribeTable failed: error=-2202" if the fields do not match the RMS Index segments.


Note 3) Sometimes the Query Processor can not know that an RMS index is not selective enough or otherwise undesirable for usage. In those cases that key can be omitted in the <KEYS> section or incorrect Nrows counts provided to coerce the QP to consider the key or not.