Failure when executing JSMDirect Service entry flagged as RDMLX
|Date:||17 May, 2007|
|Product/Release:||LANSA Integrator - EPC 805|
|Abstract:||Failure when executing JSMDirect Service entry flagged as RDMLX|
|Submitted By:||LANSA Technical Support|
EPC805 for LANSA Integrator on iSeries introduces a means of flagging a JSMDirect service entry as using RDMLX.
That is, if the flag is set, the invoked process/function is an RDMLX function and some overhead can be saved when invoking it.
When this flag is set, it is necessary to have the LANSA communications library (eg: DC@COMLIB) in the library list for the HTTP CGI job. This is because the RDMLX run-time is linked with service programs that reside in the communications library and must be located using the library list.
The library list is usually manipulated for JSMDirect requests by means of the JSMDRTEXT exit program. A standard installation creates a version of this program that adds the <program> and <data> libraries to the library list, but not the communications library.
Unfortunately a LANSA Integrator installation that uses a JSMDRTEXT program with this logic may fail with an error like the following (in the joblog for the HTTP CGI job):
Cannot resolve to object LXUTIL. Type and subtype X’0203’ Authority X’0000’
One possible resolution is to remove the RDMLX flag for the service entry in the DC@W29 file. The JSMDirect service entry will still be effective and the RDMLX function will be invoked to service matching requests but at the expense of a small overhead relative to invoking the function directly through the RDMLX run-time. An alternate resolution is to amend the JSMDRTEXT program to add and remove the <program> and <comms> to/from the library list. (A later version of LANSA Integrator will adopt this behaviour for new installations of LANSA Integrator).