18.4.6 HSKC Parameter

The HSKC=Y parameter may be specified (or defaulted) on the X_RUN command

When this value is used, "High Speed Key Checking" is enabled. This feature should only be used for Windows or Linux platforms.

When this parameter is enabled, all eligible FILECHECK RDML commands and OAM based "File Lookup Checks" will automatically track key values that have previously been found to exist in the associated SQL table(s). These tracked key values are held in memory and are much faster to (re)access second and subsequent times.

By using the HSKC= parameter selectively on relatively static decode and validation tables you can significantly improve the performance of an application.

For example, there may exist an SQL table called COMPANY that contains the identifiers of all valid companies within your application. Many other SQL tables such as CUSTOMER, ORDER, PRODUCT, etc. may have referential integrity checks against the COMPANY table that are invoked whenever information is inserted, updated or deleted.

When performed under SQL, these lookup checks into COMPANY are relatively expensive, but with the HSKC=Y parameter, all (re)checks of the same key value (i.e. the company identifier) against the COMPANY table are much cheaper and faster to execute.

Typically, eligible files include relatively static tables such as "Company Names", "Zip Codes", "Currency Codes", etc. that are used extensively for validation.

Before using this facility you should be aware of the following:

• You must nominate the names of all Physical Files/SQL tables that are eligible for this type of processing in a simple text file named X_HSKC.DAT in the main x_lansa directory of your Visual LANSA system. This file is used at execution time, so it must be present on development and execution systems.

• File X_HSKC.DAT is a simple text file that can be created and edited with most standard source file editors. Specify the name of only one file/table per line. Upper or lower case characters may be used in the names. Only the physical file/SQL table names need be specified. All logical views of the table are implicitly included when the physical file is named. The name of the file must be the first thing on the line. Leading blanks are significant and are not ignored.

• No checking of any type is done on the names specified in X_HSKC.DAT. If you enter an invalid or incorrect file name it will be accepted, and the correct file will not be subject to the HSKC=Y effects.

• If you use the HSKC=Y parameter and attempt to do a file lookup check for file X_HSKC.DAT, if it does not exist in the x_lansa directory, a fatal error will result, terminating the application.

• Updates or deletes made to a table from within the current X_RUN process/session cause all tracked details for the table to be dropped (thus restarting the tracking process again).
  
  However, you must note that only updates and deletes issued from within the current X_RUN process/session cause this to happen. Updates and deletes issued by other network users, or to an IBM i server (via LANSA SuperServer), or via other X_RUN processes, do not cause the tracked key data to be dropped from the current X_RUN session.

• The amount of key data that can be tracked is limited to the memory size of your computer. Tracked key data uses the aggregate byte length of the key involved + 2 bytes for each key value that is being tracked.

• High Speed Key Checking is not implemented for Char, String, NChar or NVarChar keys.

High Speed Key Checking for OAM based 'File Lookup Checks' is relevant for Windows and Linux platforms only. That is, if the server is a Windows or Linux server then this parameter is relevant. It is not relevant for a Visual LANSA to IBM i set up. However, for FILECHECK RDML commands, the Visual LANSA IBM i set up is fine. If you want to speed up the static files on the IBM i, then you should use the 'High Speed table' option on these files. This should yield a significant improvement in performance.