IBM Support

WDI 3.2 triggering, not working with MQ 6.0, or when migrating WDI 3.2 to 3.3 on AIX 64 bit operating system.

Question & Answer


Question

You are upgrading from WebSphere® Data Interchange (WDI) 3.2 to 3.3 and need to upgrade your WebSphere MQ (WMQ) to 6.0, as WDI 3.3 is not supported with WMQ 5.3. When you attempt to run the WDI trigger adapter: " runmqtrm -m my.queue.manager -q WDI.INIT.Q" you receive the following error: "exec(): 0509-036 Cannot load program /usr/bin/runmqtrm because of the following errors: 0509-150 Dependent module /usr/mqm/lib/libmqmcs_r.a(shr.o) could not be loaded. 0509-124 The program is a discontinued 64-bit object file."

Cause

WDI 3.2 and 3.3 are 32-bit applications . They can not use the default 64 bit libraries installed with WMQ 6.0 when installed on the AIX 64 bit kernel. In previous versions of MQ the installation process creates symbolic links from files located in /usr/mqm/lib to the /usr/lib directory. The WebSphere MQ 6.0 install procedure instructs users to remove these symbolic links (Soft Links) in /usr/lib.

This poses a new issue where the edimqs module in WDI will fail to load, as it could not locate the libmqm_r.a module. This is because the symbolic links no longer exist and you may receive a similar error in the wdiadapter.trace file.

Browse message ended with reason code = 0
WDIAdapter set Trigger Control Off
Terminating the translator...
WDI Translator Terminated, API return code = 0
Unable to open module: edimqs,
Error: 2/A file or directory in the path name does not exist.
Unable to open module: edimqs,
Error: 2/A file or directory in the path name does not exist.

Answer


Step 1:
To resolve the error:"0509-124 The program is a discontinued 64-bit object file"
You must remove the symbolic links ( Soft Links ) in /usr/lib that point to the 64 bit libraries for WMQ 6.0

Step 2:
To resolve the error: "Unable to open module: edimqs"

WDI 3.2 or 3.3 temporary solution to the problem:
To work around this problem you can modify the Application Identifier field in the WMQ Process Definition for WDI.PROC to look like this:

WDI 3.2 -WDI.PROC



WDI 3.3 - WDI.PROC



By adding the LIBPATH=/usr/mqm/lib:$LIBPATH to the Application ID field when the runmqtrm executable creates a new shell and executes the WDIAdapter program the LIBPATH environment variable will contain the correct paths to locate the MQ libraries but will not interfere with the MQ commands.


Setting LIBPATH to Include MQ Library Directory:
Because of the way WebSphere MQ locates its modules, updating the LIBPATH to include the /usr/mqm/lib directory in a shell where MQ Series commands are going to be executed will cause errors. The MQSeries commands need to be run in a shell where LIBPATH has not been updated to include this path. If you set LIBPATH in a shell where you will be running an MQ command you will see this error.

exec(): 0509-036 Cannot load program /usr/bin/runmqtrm because of the following errors:

0509-150 Dependent module /usr/mqm/lib/libmqmcs_r.a(shr.o) could not be loaded.
0509-124 The program is a discontinued 64-bit object file.

This is why in the above solution we modified the Application ID field. This will set the proper LIBPATH environment for WDI to run but will not interfere with the MQSeries environment.



WDI 3.3 permanent solution to the problem:
In the future, the WebSphere Data Interchange 3.3 build environment will be modified as an APAR fix, so that LIBPATH includes /usr/mqm/lib. By doing this, the WDI system will automatically include /usr/mqm/lib in the search as edimqs is loaded. Once this change is put into effect step two of this document will not be needed.

[{"Product":{"code":"SSFKTZ","label":"WebSphere Data Interchange"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"WDI 3.3 MP","Platform":[{"code":"PF002","label":"AIX"}],"Version":"3.2;3.2.1;3.3","Edition":"","Line of Business":{"code":"LOB59","label":"Sustainability Software"}}]

Document Information

Modified date:
16 June 2018

UID

swg21279263