Creating queue managers on Multiplatforms

Before you can use messages and queues, you must create and start at least one queue manager and its associated objects. A queue manager manages the resources associated with it, in particular the queues that it owns. It provides queuing services to applications for Message queuing Interface (MQI) calls and commands to create, modify, display, and delete IBM® MQ objects.

Before you begin

Important: IBM MQ does not support machine names that contain spaces. If you install IBM MQ on a computer with a machine name that contains spaces, you cannot create any queue managers.

Before you can create a queue manager, there are several points that you must consider, especially in a production environment. Work through the following checklist:

The installation associated with the queue manager

To create a queue manager, you use the IBM MQ control command crtmqm. The crtmqm command automatically associates a queue manager with the installation from which the crtmqm command was issued. For commands that operate on a queue manager, you must issue the command from the installation associated with the queue manager. You can change the associated installation of a queue manager using the setmqm command. Note that the Windows installer does not add the user that performs the installation to the mqm group, for more details, see Authority to administer IBM MQ on AIX®, Linux®, and Windows.

Naming conventions

Use uppercase names so that you can communicate with queue managers on all platforms. Remember that names are assigned exactly as you enter them. To avoid the inconvenience of lots of typing, do not use unnecessarily long names.

Specify a unique queue manager name

When you create a queue manager, ensure that no other queue manager has the same name anywhere in your network. Queue manager names are not checked when the queue manager is created, and names that are not unique prevent you from creating channels for distributed queuing. Also, if you use the network for publish/subscribe messaging, subscriptions are associated with the queue manager name that created them. Therefore if queue managers in the cluster or hierarchy have the same name, it can result in publications not reaching them.

One way of ensuring uniqueness is to prefix each queue manager name with its own unique node name. For example, if a node is called ACCOUNTS, you can name your queue manager ACCOUNTS.SATURN.QUEUE.MANAGER, where SATURN identifies a particular queue manager and QUEUE.MANAGER is an extension you can give to all queue managers. Alternatively, you can omit this, but note that ACCOUNTS.SATURN and ACCOUNTS.SATURN.QUEUE.MANAGER are different queue manager names.

If you are using IBM MQ for communication with other enterprises, you can also include your own enterprise name as a prefix. This is not shown in the examples, because it makes them more difficult to follow.

Note: Queue manager names in control commands are case-sensitive. This means that you are allowed to create two queue managers with the names jupiter.queue.manager and JUPITER.queue.manager. However, it is better to avoid such complications.

Consider the coded character set identifier

The queue manager has an associated coded character set identifier (CCSID), which specifies the code page that is used for character or string data within the queue manager. This data includes configuration data, such as object names and descriptions, and any data that enters or leaves the queue manager (for example, through the MQI and other messaging APIs) where that data does not explicitly identify the code page to use. For example, the code page for character data within a message body is explicitly identified by the CCSID field in the message descriptor (MQMD). However, character data within the MQMD is assumed to be in the CCSID of the local queue manager (though this can be converted, where possible, at the entry or exit interfaces, for example during an MQGET call).

You might need to consider the CCSID, for example if you have a distributed messaging system with queue managers on different operating systems or in different countries. The CCSID is selected automatically when you create the queue manager, depending on the platform and locale of the user that runs the crtmqm command:

On Windows and all Linux platforms, the CCSID is the first CCSID in the ccsid_part2.tbl file that matches the character set of the current locale.
On AIX, character conversion is handled by the operating system, and system libraries are also queried for the appropriate CCSID based on the locale at queue manager creation. For example, you can use the export LANG=C command to set the locale to C, which uses the codeset ISO8859-1 and sets the queue manager's CCSID to 819. The locales that are available depend on the AIX filesets that are installed on the system. For example, if you want to convert data to and from Unicode, install the filesets that are listed in the "Unicode support on AIX" section of Hardware and software requirements on AIX systems.
On IBM i, the queue manager obtains its CCSID value from the job that created the queue manager. If that job has a special CCSID value of 65535, the default job CCSID is used, which is derived from the LANGID of the job. For example, LANGID(ENU) results in a default CCSID of 37. To determine the effective CCSID value that will be used when you create the queue manager, enter DSPJOB OPTION(*DFNA) then page through the output to see the Coded character set identifier, Language Identifier, and Default coded character set identifier values. To change either the CCSID or LANGID values, use the CHGJOB command.

You can identify the character set for the current locale by using the

locale
charmap

command on AIX and Linux systems, and the chcp command on Windows. To show the CCSID of the queue manager after it is created, use the

DISPLAY
QMGR

MQSC command.

If you need to specify a different CCSID, you can do so after you create the queue manager, by using the ALTER QMGR MQSC command, the MQCMD_CHANGE_Q_MGR PCF command, or (on IBM i systems) the CHGMQM CL command.

Limit the number of queue managers

You can create as many queue managers as resources allow. However, because each queue manager requires its own resources, it is generally better to have one queue manager with 100 queues on a node than to have ten queue managers with ten queues each.

In production systems, many processors can be exploited with a single queue manager, but larger server machines might run more effectively with multiple queue managers.

Specify a default queue manager

Each node should have a default queue manager, though it is possible to configure IBM MQ on a node without one. The default queue manager is the queue manager that applications connect to if they do not specify a queue manager name in an MQCONN call. It is also the queue manager that processes MQSC commands when you invoke the runmqsc command without specifying a queue manager name.

Specifying a queue manager as the default replaces any existing default queue manager specification for the node.

Changing the default queue manage can affect other users or applications. The change has no effect on currently-connected applications, because they can use the handle from their original connect call in any further MQI calls. This handle ensures that the calls are directed to the same queue manager. Any applications connecting after you have changed the default queue manager connect to the new default queue manager. This might be what you intend, but you should take this into account before you change the default.

Creating a default queue manager is described in Creating a default queue manager.

Specify a dead-letter queue

The dead-letter queue is a local queue where messages are put if they cannot be routed to their intended destination.

It is important to have a dead-letter queue on each queue manager in your network. If you do not define one, errors in application programs might cause channels to be closed, and replies to administration commands might not be received.

For example, if an application tries to put a message on a queue on another queue manager, but gives the wrong queue name, the channel is stopped and the message remains on the transmission queue. Other applications cannot then use this channel for their messages.

The channels are not affected if the queue managers have dead-letter queues. The undelivered message is put on the dead-letter queue at the receiving end, leaving the channel and its transmission queue available.

When you create a queue manager, use the -u flag to specify the name of the dead-letter queue. You can also use an MQSC command to alter the attributes of a queue manager that you have already defined to specify the dead-letter queue to be used. See Displaying and altering queue manager attributes for an example of the MQSC command ALTER.

Specify a default transmission queue

A transmission queue is a local queue on which messages in transit to a remote queue manager are queued before transmission. The default transmission queue is the queue that is used when no transmission queue is explicitly defined. Each queue manager can be assigned a default transmission queue.

When you create a queue manager, use the -d flag to specify the name of the default transmission queue. This does not actually create the queue; you have to do this explicitly later on. See Working with local queues for more information.

Specify the logging parameters you require

You can specify logging parameters on the crtmqm command, including the type of logging, and the path and size of the log files.

In a development environment, the default logging parameters should be adequate. However, you can change the defaults if, for example:

You have a low-end system configuration that cannot support large logs.
You anticipate a large number of long messages being on your queues at the same time.
You anticipate a lot of persistent messages passing through the queue manager.

Once you have set the logging parameters, some of them can only be changed by deleting the queue manager and recreating it with the same name but with different logging parameters.

For more information about logging parameters, see Logging: Making sure that messages are not lost.

For IBM MQ for UNIX systems only

You can create the queue manager directory /var/mqm/qmgrs/qmgr, even on a separate local file system, before you use the crtmqm command. When you use crtmqm, if the /var/mqm/qmgrs/qmgr directory exists, is empty, and is owned by mqm, it is used for the queue manager data. If the directory is not owned by mqm, the creation fails with a First Failure Support Technology ( FFST ) message. If the directory is not empty, a new directory is created.

About this task

To create a queue manager, you use the IBM MQ control command crtmqm. For more information, see crtmqm. The crtmqm command automatically creates the required default objects and system objects (see System default objects). Default objects form the basis of any object definitions that you make; system objects are required for queue manager operation.

[Windows] On Windows systems you have the option to start multiple instances of the queue manager by using the sax option of the crtmqm command.

When you have created a queue manager and its objects, you can use the strmqm command to start the queue manager.