WebSphere Message Broker V8.0 adds support for WebSphere MQ V7.1 and V7.5 in addition to V7.0.1

News


Abstract

WebSphere Message Broker V8.0 adds support for WebSphere MQ V7.1 and V7.5 in addition to V7.0.1

Content

WebSphere Message Broker V8.0.0.1 introduces support for WebSphere MQ V7.1 and V7.5 for the first time. There are some changes in behaviour and new features in MQ V7.1 that Message Broker users should be aware of:
1) Multiple installations
On UNIX, Linux, and Windows, it is possible to have more than one copy of WebSphere MQ on a system.

It introduces the concept of 'primary' and 'non-primary' installations.
A primary MQ installation exhibits many of the same characteristics as previous versions of MQ. For example, the MQ commands and libraries are available to be called on the system without having to know or set the location of the MQ installation. Only one primary installation can exist on an operating system image. If MQ V7.0.1.x is installed, this must be the primary installation.
For a non-primary installation, no system level links or environment variables are set by default. The user must know the location of the MQ installation that they wish to use.

For more details, please refer to Multiple Installations

2) Channel authentication is enabled for new queue managers
Within MQ v7.0.1, channel authentication security is not enabled by default. This has been changed in MQ v7.1 where security is enabled on newly created queue managers. This means that clients are unable to connect via a channel connection if they are using a user ID within the MQ administrators group (mqm). This means that a different, non MQ administrator user ID must be used when access is required. WebSphere Message Broker components such as the Toolkit and the Default Configuration Wizard both make the assumption that they can create artefacts (such as queue managers) requiring administrator privileges and also access MQ via a channel.


How do the above two WebSphere MQ V7.1/V7.5 features affect WebSphere Message Broker V8.0.0.1 and later?


Channel authentication security
Taking the channel authentication security issue first, since this is the most straightforward, WebSphere Message Broker V8.0.0.1 has been modified as follows:

  • When a broker is created (via the command line, Toolkit, Default Configuration Wizard, etc.) specifying a queue manager name that does not already exist, the channel authentication security will be automatically disabled against the queue manager, allowing the previous (MQ V7.0.1 and earlier) behaviour to be exhibited. If the user subsequently wishes to enable channel authentication security, the steps required to achieve this are documented in the WebSphere Message Broker information center.
  • If the queue manager specified when creating the broker already exists, then it will be assumed that the user has applied the appropriate security configuration to meet their requirements, therefore, channel authentication will not be disabled.
Note that channel authentication is disabled by default on queue managers that have been migrated to MQ V7.1 from earlier versions.


Multiple MQ installations
The multiple MQ installation support is a little more complicated and whilst every effort has been made to shield the user from this complexity, it is worth being aware of how the various broker components now behave to be able to support MQ V7.0.1, MQ V7.1 and MQ V7.5.

Message Broker Runtime
UNIX, Linux, and Windows platforms only.
Previously to WebSphere Message Broker v8.0.0.1, the broker would expect that the environment settings would contain information about the location of the MQ installation, and the library paths to use to locate the required MQ libraries and jar files.

On UNIX and Linux, the broker's mqsiprofile would set the required environment variables knowing the MQ libraries had a fixed install location. On Windows, the MQ install location was not fixed, but it was expected that the MQ installation process would set the required environment variables that the broker would then pick up.

WebSphere MQ V7.1 and later provides support for multiple installations, which implies that the MQ installation directory on UNIX and Linux is no longer fixed. Therefore the broker's mqsiprofile no longer adds the MQ installation path to the appropriate environment variables on UNIX and Linux. Instead, given that a broker is always associated with one specific queue manager and queue managers are "owned" by a particular installation, the broker runtime component will dynamically find the appropriate MQ installation path based on the broker's queue manager name and load the necessary libraries.

The same is true on Windows if WebSphere MQ v7.1 or later is found on the system. But if only WebSphere MQ v7.0.1 is present, the broker will still use the Windows environment variable settings for MQ to locate the MQ installation.

Message Broker Commands
UNIX, Linux, and Windows platforms only.
Some broker commands in turn call standard MQ commands or need to call MQ library functions. So similarly to the broker runtime, the commands need to locate the correct MQ installation path to use.

If a broker name is provided as one of the parameters to the command, then this will be used to dynamically locate the MQ installation from the broker's queue manager name. The exception is mqsicreatebroker for the case when the specified queue manager does not currently exist (to be created by the mqsicreatebroker command). In this case the user needs to ensure that the current environment settings identify the correct MQ installation to use, either by having a primary MQ installation or by setting the environment manually via the MQ command setmqenv.

If a broker name is not provided as a command parameter, but MQ interaction is still required (for example, with some forms of the mqsilist command), the latest version of MQ found on the system will be used. This is because MQ V7.1 and V7.5 installations can talk to MQ v7.0.1, V7.1 and V7.5 systems via "library switching", but this is not true for MQ v7.0.1 installations.

WebSphere Message Broker Explorer
Each MQ installation on a system will have it's own MQ Explorer, and each instance of MQ Explorer will only allow the user to administer queue managers that are owned by the same installation.

The WebSphere Message Broker Explorer installation will add links to all the existing MQ Explorer installations found on the system, and will this inherit the MQ installation path from the MQ Explorer that is invoked. Similarly to MQ Explorer, WebSphere Message Broker Explorer will only allow the user to administer brokers which have associated queue managers owned by the same MQ installation as the MQ Explorer being used. Other brokers may be viewed, but cannot be administered.

WebSphere Message Broker Toolkit
The WebSphere Message Broker Toolkit v8.0.0.1 and later will find and use the latest MQ version on the system. This implies that the Default Configuration Wizard will create a new broker with a new queue manager that is automatically associated with the latest version of MQ on the system. Similarly with a new local broker created via the Toolkit. If a broker created by the Default Configuration Wizard already exists, having been created using an earlier MQ version, it will need to be deleted and recreated.


Potential problems

On AIX, the following error may be seen when starting a broker on a system with only MQ V7.0.1 installed (and therefore the primary installation):

BIP2114E: Message broker internal error: diagnostic information 'MqLibraryLoader: can not load MQ libraries from Installation Path', '/usr/mqm/lib64/libmqm_r.a(libmqm_r.o)', 'Could not load module /usr/mqm/lib64/libmqm_r.a(libmqm_r.o). Dependent module /usr/lib/libmqz_r.a(libmqz_r.o) could not be loaded. The module has an invalid magic number. Could not load module /usr/mqm/lib64/libmqm_r.a(libmqm_r.o). Dependent module /usr/mqm/lib64/libmqm_r.a(libmqm_r.o) could not be loaded.', ' Removing the MQ symbolic links within /usr/lib via the MQ command dltmqlnk may resolve the problem.'.
BIP8875W: The component verification for 'brokerName' has finished, but one or more checks failed.

As per the message detail highlighted in bold italic text above, the user should first try removing the MQ symbolic links within /usr/lib via the MQ command dltmqlnk as this is likely to resolve the problem.

Product Alias/Synonym

WMB MB WebSphere Message Broker MQ Integrator WBIMB WBI-MB MQSI WMQI

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

WebSphere Message Broker
MQSeries

Software version:

8.0, 8.0.0.1

Operating system(s):

AIX, HP-UX on Itanium, Linux, Solaris, Windows, z/OS

Reference #:

1608385

Modified date:

2012-08-17

Translate my page

Machine Translation

Content navigation