Installing IBM MQ to interoperate with WebSphere Application Server

When you install a new IBM MQ network, you can tune the installation for working with WebSphere® Application Server. If you have an established IBM MQ network, you can choose whether to modify some of the settings for better interoperation.

1. [In IBM MQ] Install a supported version of IBM MQ, as described in the installation instructions provided with IBM MQ.

   To identify the supported version of IBM MQ, see the following article: Detailed system requirements page.

   You can not install Rational® Application Developer and WebSphere Application Server on the same machine when using IBM MQ.

   See the following for other installation prerequisites of different IBM MQ releases:

   • Version 7.0.1: see the Quick Beginnings section for your platform, in the IBM MQ product information.
   • Version 7.1: see the Installing and uninstalling section in the IBM MQ product documentation.
   • Version 7.5: see the Installing and uninstalling section in the IBM MQ product documentation.
2. [In IBM MQ] Follow the IBM MQ instructions for verifying your installation setup.
   You can verify the server installation either using the command line or using the postcard application.

   • Version 7.0.1: see the verifying link in the Quick Beginnings section for your platform, in the IBM MQ product information.
   • Version 7.1: see Verifying a server installation.
   • Version 7.5: see Verifying a server installation.
3. [In WebSphere Application Server and IBM MQ] Configure WebSphere Application Server and IBM MQ to interoperate effectively.
4. [In WebSphere Application Server] Configure the IBM MQ messaging provider with native libraries information.

   To connect to an IBM MQ queue manager or queue-sharing group in bindings mode, the IBM MQ messaging provider needs to know where to load native libraries from. For more information, see Configuring the IBM MQ messaging provider with native libraries information.

   Note: For migration purposes only, you can also specify native path information, when in an application server environment, by setting the MQ_INSTALL_ROOT WebSphere Application Server environment variable. For more information, see Installing IBM MQ to interoperate with WebSphere Application Server.
5. Optional: [In WebSphere Application Server] At Cell scope or Node scope, set the WebSphere Application Server MQ_CLEAR_MQ_FROM_OSGI_CACHE_ON_SHUTDOWN environment variable to True.
   This allows application server startup to automatically take account of changes that are made to the MQ_INSTALL_ROOT environment variable and IBM MQ JMS client libraries while the application server is stopped.

   If you do not set this variable, you must restart the application server a second time after any changes of this type, to enable the application to perform messaging by using the IBM MQ messaging provider.

   Attention: If you set the MQ_CLEAR_MQ_FROM_OSGI_CACHE_ON_SHUTDOWN environment variable, the startup time might increase because, on startup, each application server needs to initialize an additional state associated with IBM MQ installation.

   For any change in the IBM MQ product (such as a PTF upgrade), you must restart WebSphere Application Server and all nodes.

6. Optional: [In WebSphere Application Server] At Cell scope or Node scope, set the WebSphere Application Server MQ_USE_BUNDLE_REFERENCE_INSTALL environment variable to True.
   When this variable is set to True, the IBM MQ JMS bundle is installed using a reference installation.

   The OSGi framework shares a storage area on disk. Because all servers of the installation use this storage area, multiple servers in the installation might read and or write data to this storage area concurrently, causing resource contention. The likelihood of a contention scenario occurring increases if the MQ_CLEAR_MQ_FROM_OSGI_CACHE_ON_SHUTDOWN variable is set to True. Setting the MQ_USE_BUNDLE_REFERENCE_INSTALL variable to True causes the IBM MQ JMS bundle to be installed using a reference installation, thereby avoiding the need for the OSGi framework to persist the IBM MQ JMS bundle file to the shared storage area. Instead, each server and controller creates a unique bundle file for its use.