Here are some other topics that you should consider when preparing WebSphere MQ for distributed queue management.
A DLQ handler is provided with WebSphere MQ for z/OS, MQSeries for OS/2 Warp , WebSphere MQ on UNIX systems, Compaq OpenVMS Alpha and Compaq NonStop Kernel. See the WebSphere MQ System Administration Guide book for WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, and Windows systems, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp for information about this.
MCAs for receiver channels may keep the destination queues open even when messages are not being transmitted; this results in the queues appearing to be "in use".
This section deals with remote messaging aspects of security.
You need to provide users with authority to make use of the WebSphere MQ facilities, and this is organized according to actions to be taken with respect to objects and definitions. For example:
The message channel agent at a remote site needs to check that the message being delivered originated from a user with authority to do so at this remote site. In addition, as MCAs can be started remotely, it may be necessary to verify that the remote processes trying to start your MCAs are authorized to do so. There are three possible ways for you to deal with this:
Administration users must be part of the mqm group on your system (including root) if this ID is going to use WebSphere MQ administration commands. In Compaq OpenVMS Alpha, the user must hold the mqm identifier.
You should always run amqcrsta as the "mqm" user ID.
In Compaq OpenVMS Alpha, all user IDs are displayed in uppercase. The queue manager converts all uppercase or mixed case user identifiers into lowercase, before inserting them into the context part of a message, or checking their authorization. All authorizations should therefore be based only on lowercase identifiers.
When the listener program (amqcrsta, for example) is started by INETD it inherits the locale from INETD. It is possible that the MQMDE will not be honored and will be placed on the queue as message data.
To ensure that the MQMDE is honored (merged) the locale must be set correctly. The locale set by INETD may not match that chosen for other locales used by WebSphere MQ processes.
To set the locale, create a shell script which sets the locale environment variables LANG, LC_COLLATE, LC_CTYPE, LC_MONETARY, LC_NUMERIC, LC_TIME, and LC_MESSAGES to the locale used for other WebSphere MQ processes. In the same shell script call the listener program. Modify the inetd.conf file to call your shell script in place of the listener program.
Administration users must be part of both the mqm group and the administrators group on Windows systems if this ID is going to use WebSphere MQ administration commands.
On Windows systems, if there is no message exit installed, the queue manager converts any uppercase or mixed case user identifiers into lowercase, before inserting them into the context part of a message, or checking their authorization. All authorizations should therefore be based only on lowercase identifiers.
Platforms other than Windows systems and UNIX systems use uppercase characters for user IDs. To allow Windows systems and UNIX systems to use lowercase user IDs, the following conversions are carried out by the message channel agent (MCA) on these platforms:
Note that the automatic conversions are not carried out if you provide a message exit on UNIX systems and Windows systems for any other reason.
The user identifier service enables queue managers running under OS/2 to obtain a user-defined user ID. This is described in the WebSphere MQ Programmable Command Formats and Administration Interface book.
A facility is provided in the channel definition to allow extra programs to be run at defined times during the processing of messages. These programs are not supplied with WebSphere MQ, but may be provided by each installation according to local requirements.
In order to run, these user-exit programs must have predefined names and be available on call to the channel programs. The names of the user-exit programs are included in the message channel definitions.
There is a defined control block interface for handing over control to these programs, and for handling the return of control from these programs.
The precise places where these programs are called, and details of control blocks and names, are to be found in Part 7, Further intercommunication considerations.
If performance is an important consideration in your environment and your environment is stable, you can choose to run your channels and listeners as trusted, that is, using the fastpath binding. There are two factors that influence whether or not channels and listeners run as trusted.
You can use MQIBindType in association with the environment variable to
achieve the desired affect as follows:
| MQIBindType | Environment variable | Result |
|---|---|---|
| STANDARD | UNDEFINED | STANDARD |
| FASTPATH | UNDEFINED | FASTPATH |
| STANDARD | STANDARD | STANDARD |
| FASTPATH | STANDARD | STANDARD |
| STANDARD | FASTPATH | STANDARD |
| FASTPATH | FASTPATH | FASTPATH |
In summary, there are only two ways of actually making channels and listeners run as trusted:
You are recommended to run channels and listeners as trusted only in a stable environment in which you are not, for example, testing applications or user exits that may abend or need to be cancelled. An errant application could compromise the integrity of your queue manager. However, if your environment is stable and if performance is an important issue, you may choose to run channels and listeners as trusted.