Rules You Must Understand Before Using a Function Routing Table
- On a IBM i, Function routing tables must reside in the partition's module library or another library, if *FUNRTRLIBL is set. If a library other than the partition's module library is used it must be in the library list when the LANSA command executes. If it is not the existence of the routing file will not be recognized.
You set *FUNRTRLIBL via the option in .
- For PC applications, Function routing tables must reside in the source directory. If the routing table is not placed into the correct directory then its existence will not be recognized.
- Function routings are partition based, and only apply to, the partition that is associated with the routing table.
- You can only specify a single function routing per line, in the form fffffff,ttttttt in a function routing table. The from function (fffffff) must begin in column 1. It must be immediately followed by a single comma, which in turn must be followed by the to function (ttttttt) name. No other information can be included in the routing entry line. Entries that do not follow these formatting rules will be ignored and no exception is issued or noted.
- From and to function names in the routing table must be specified in uppercase characters.
- Up to 4500 entries can be specified in the function routing table (comments are not included in this count). Entries beyond entry number 4500 are ignored and no warning or error message is issued.
- You must not use the reserved function names EXIT, EOJ, MENU, RETRN, ERROR, HELP, SELECT, EOJ, *ANY, Cn, Fn or Pn (where "n" is in the range 1 to 999999) as either the "to" or "from" function names in a function routing table. Use of these reserved names may cause unpredictable results and/or application failure.
- You can enter comments into a function routing table. If a function routing table entry line starts with an "*" in column 1, it is regarded as a comment and it is ignored. For example:
* Route all standard reports to tailored versions
GLR01,GLR0101
GLR02,GLR0201
GLR03,GLR0301
* End of routing table
- The function routing table is loaded into memory at the time that the LANSA (IBM i) or X_RUN (PC) command is invoked. This is done to optimize access to the routing entries in the table. It also means that changes you make to a routing table will not be effectively recognized until you exit and re-invoke the LANSA or X_RUN command.
- The function routing table is looked up once for a "from" function, to find a "to" function. Once a "to" function has been located, it is not looked up again. You must not form routing "chains". The example below must not be used to route a direct reference of A to A2. The Function Routing Table Verification will produce warnings if you do this and unpredictable results or errors may occur at execution time.
A,A1
A1,A2
Function Routing Table Verification
While all these rules may seem complex, a facility is provided that allows you to verify the contents of your FRT (Function Routing Table) after it has been updated. To use this facility you must:
- Update the FRT as required.
- On an IBM i system: use the command LANSA REQUEST(VERIFYFRT) PARTITION(ppp). This command will produce a spool file (QSYSPRT) that details the verification of your updated FRT. You should review all the messages in this file, and if required, take corrective action before running the verification process again.
- On a PC system: use the command X_RUN PROC=*VERIFYFRT PART=DEM USER= etc, etc (refer to the X_RUN command for details of other parameters). This command will produce a display that details the verification of your updated FRT. You should review all the messages in this file, and if required, take corrective action before running the verification process again.
The reason that the "update-verify" model has been chosen for the FRT (Function Routing Table) is simply that the load and lookup of the FRT has to be optimized for performance. This means that no effective analysis of the FRT can be performed when it is actually being used because the performance impacts would be significant.
Finally, the fatal error notification panel, used for IBM i applications notes, that function routing was in effect at the time that the application failed. This is a visual reminder that the presence and use of the FRT should be taken into account when you are trying to determine the cause of the application error.