On an IBM i, when you start a LANSA application running via the LANSA command, the data area DC@OSVEROP is examined for the flag *FUNRTRLIBL.
You set *FUNRTRLIBL via the Use function routing table from *LIBL option in Work with Execution and Security Settings.
On a PC, when you start a LANSA application running via the the X_RUN command, a check is made for the existence of a file called X_FUNRTR (i.e. a Function Routing Table) in the directory associated with the current partition.
If an X_FUNRTR file is found then its entries are loaded into memory. (This is why you must exit and re-invoke any active LANSA or X_RUN command for any changes that you make to the function routing table to become effective). All entries in the table are sorted into order, to optimize the time it takes to look up the table. Finally, a system-wide flag is set to indicate that function (re)routing is in effect.
The setting of the system flag is very significant because every single function call operation in LANSA is sensitive to the setting of this flag. The following "invoke a function" logic demonstrates why this is significant:
if (function routing is in effect)
test to see if call to specified function should
be (re)routed
if it should be rerouted replace specified function name
with(re)routed name
endif
invoke the specified function
You can see that where function routing is not in effect, no significant performance impact exists (other than to test the system-wide flag).
However, when function routing is in effect, a performance impact results in all invoked function operations because the function name has to be looked up in the function routing table. Also there is an overhead when LANSA is started because the Function Routing Table has to be sorted and loaded. The larger the table the more time required for this initial load.
The function routing table is not checked for LANSA debug. Therefore, if it is required to debug a routed function, the "to" function must be specified when turning on debug mode.
