&<img src="../resources/images/opentocr.png" title="Open Contents list" border="0"&>
You are here:

PJC Considerations

Following are some important considerations for using PJCs:

• Although the predetermined join column processing is coded within the OAM,  the related tables are only accessed when one of the predetermined join columns is specifically used. This make PJCs very efficient, i.e. they do not impact table access times when they are not used.
• If the table to be accessed by the access route is defined as an IBM i high speed table, the source information for the predetermined join columns will be retrieved from the high speed table, thereby improving performance and reducing I/Os.
• When defining predetermined join columns, careful thought should be given to  their use.  They are very efficient for looking up code tables for descriptions when used with a KEEP LAST value or for accessing a high speed table. If they are used excessively, each table accessed will affect the number of tables used in the OAM and DBOPTIMISED functions. (For more details, refer to Using *DBOPTIMIZE / *DBOPTIMIZE_Batch in the LANSA for i User Guide.)
• If the function has been DBOPTIMISED the predetermined join column processing will have been included in the OAM logic which is embedded in the function.
• PJCs could greatly increase the number of I/Os performed by the OAM where there are 1:m relationships. For example, each time a single record is read from the Department table, it must access all related records in the Section table if the Section Count column is required.
• Predetermined join columns will appear in the list of columns in the table, but they are maintained using the access routes.
• As a guide, do not access more than 10 to 15 tables for Predetermined Join Columns.

&<img src="../resources/images/opentoc-dark.png" title="Open Contents List" border="0"&>