I have been testing Capitalware products (various exits) on different platforms with WebSphere MQ v7.1 & v7.5 and life was going along very well.

I had a customer (who uses our security exit) just contacted me saying that they have a Linux server with 3 different releases of MQ installed (v7.0.1.9, v7.1.0.0 and v7.5.0.1) where WMQ v7.5.0.1 is installed in a non-default location.

When they moved a queue manager from using WMQ v7.0.1.9 (in the default install location) to v7.5.0.1 (non-default install location), they got the following error:

08/04/13 17:00:10 - Process(18418.4) User(mqm) Program(amqrmppa)
                    Host(servername) Installation(Installation2)
                    VRMF(7.5.0.1) QMgr(QMGRNAME)


AMQ6175: The system could not dynamically load the shared library
'/var/mqm/exits64/mqssx'. The system returned error message
'/opt/mqm/lib64/libmqz_r.so: undefined symbol: xcsAllocateMemBlock'.

EXPLANATION:
This message applies to UNIX systems. The shared library
'/var/mqm/exits64/mqssx' failed to load correctly due to a problem
with the library.

ACTION:
Check the file access permissions and that the file has not been corrupted.

After a little head scratching, found the following in the WMQ Information Center:

If WebSphere MQ is installed in a non-default location you must write and compile your exits without linking to any WebSphere MQ libraries.

You can write and compile exits on Windows, UNIX and Linux systems without linking any of these WebSphere MQ libraries:
– mqmzf
– mqm
– mqmvx
– mqmvxd
– mqic
– mqutl

Existing exits that are linked to these libraries continue to work, providing that on UNIX and Linux systems WebSphere MQ is installed in the default location.

When I read the “Procedure” section on that web page, it left me scratching my head. The new requirements is absolutely wild. Basically, it is saying that EVERY MQ exit in existence will never work with a “non-default install location” of MQ if (1) it used MQ API calls and/or (2) it has linked in MQ libraries.

Who thought this was ok?

A normal solution would be to say remove RPATH from the linking of the exit then you need to explicitly set the local path for the OS. i.e. PATH for Windows, SHLIB_PATH for HP-UX, LIBPATH for AIX & IBM i (OS/400) and LD_LIBRARY_PATH for Solaris & Linux.

For multi-installation, IBM is already setting environment variables with crtmqenv/setmqenv commands. I really don’t understand the need for this over-top solution that IBM now requires for exits.

How in the world are developers supposed to create/support an exit on WMQ installation that is less than WMQ v7.1 and greater than WMQ v7.1 at the same time? What, are we supposed to have 2 entirely different code bases for the same exit? Please don’t say, just upgrade WMQ to v7.1 or higher because customers in the real world don’t work like that (MQ multi-install.

I would say that probably 50-60% (maybe higher) of Capitalware’s customers are running a release of WMQ that is less than v7.1 (i.e. v6.0.*.* or v7.0.0.* or v7.0.1.*).

Oh the headaches and head-banging that I’m about to go through. 🙁

Regards,
Roger Lacroix
Capitalware Inc.