WebSphere MQ planning for z/OS

This is part of the larger task of customizing your z/OS environment.

You are required to have a separate WebSphere MQ queue manager for each broker, User Name Server (although you would typically have only one User Name Server in your environment), and Configuration Manager. A broker, User Name Server, and Configuration Manager however, can share the same queue manager. All WebSphere Event Broker for z/OS system queues are defined during customization.

Your queue manager needs a dead-letter queue. Check this by using the WebSphere MQ command:
+cpf  DIS QMGR DEADQ
Check the queue exists by using the command:
 +cpf DIS QL(name) STGCLASS
Then use the:
+cpf DIS STGCLASS(...)
to check the STGCLASS value is valid. If the queue manager does not have a valid dead-letter queue, you must define one.

Set up your channel initiator to use distributed queuing. You need channels between the z/OS queue manager and the queue manager of your Configuration Manager (if not on z/OS). If you are using Publish/Subscribe security, you also need access to the queue manager used by the User Name Server, which can be on z/OS or on another platform. You should be able to successfully start channels between the various queue managers before you can test that the broker is working. When configuring the transmission queues between the brokers on z/OS and the Configuration Manager, ensure you set the maximum message size of the queues to 100 MB. This allows large reply messages concerning deployment to be returned to the Configuration Manager. See Creating a domain connection for details.

Creating and deleting components on z/OS requires the command server on the WebSphere MQ queue manager to be started, which is normally done automatically (refer to the WebSphere MQ for z/OS System Administration Guide for more details).

This requires a reply-to queue based on SYSTEM.COMMAND.REPLY.MODEL; by default, this model queue is defined as permanent dynamic. However, if you leave the queue defined in this way, each time you run a create or delete component command these reply-to queues remain defined to the queue manager. To avoid this you can set the SYSTEM.COMMAND.REPLY.MODEL queue as temporary dynamic.

Related concepts
Brokers
User Name Server
Related tasks
Customizing the z/OS environment
Creating a domain connection