3.7.14 IBM i High Speed Table

Specify whether this table definition and associated indexes should be mirrored into a high-speed IBM i User Index to allow more rapid access in "read only" situations.
The following points provide basic information about the IBM i high-speed table facility. They should all be read and understood before this facility is used in any way:

...

Default = NO (unchecked/not selected).

Usage Rules

To be valid as a high-speed table a table definition must conform to the following rules. Most of these things are checked during the "make operational" phase of creating/changing a table. If a rule is violated the make operational will fail with appropriate error message(s).
These rules apply to the basic physical table definition and all logic views defined over it:

...

In summary, the high-speed table facility is designed for use with "plain vanilla" lookup and decode style tables only. Tables that are to be used in any other "fancy" way at all should not be implemented as high-speed tables.

Tips & Techniques

Some common questions about high-speed tables:

...

A high-speed table is imported to another system just like a normal table. However, if the table data is imported, or the table layout is changed, the associated index is not automatically updated/reformatted. To do this you should trigger a "resynchronization" of the table and its index using any of the techniques previously described.
Note: A user index greater than 1 gigabyte or with an entry record length greater than 108 bytes cannot be saved to or restored from an OS/400 release prior to V2R2M0.

Warnings

• It is strongly recommended that, if option *HSTABEXTEND is added to system data area DC@OSVEROP, to make either the extended entry record length available or remove it to limit entry length.  All tables tagged as high-speed tables, all read-only functions that use these tables and all other OAMs and DBOPTIMIZED functions that use high-speed tables for lookup validation rules, must be recompiled AFTER deleting the current user index. This index is DC@TBLIDX if adding *HSTABEXTEND, or  DC@TBLIDY if removing *HSTABEXTEND.
• If this is not done, all functions that use a particular table and the OAM must be recompiled at the same time or they will not be pointing to the same index. The situation will be further complicated by OAMs and DBOPTIMIZED functions which use high-speed table tables for lookup validation rules also pointing to the wrong index. It may not be obvious to the user that there is a problem as the database table and one index will be unsynchronized, but it will not cause program failure.

Platform Considerations

• IBM i: This table attribute applies to IBM i databases only.

...