Plan for the queue manager
When we are setting up a queue manager, your planning should allow for the queue manager to grow, so that the queue manager meets the needs of our enterprise.
The best way to configure a queue manager is in steps:
- Configure the base queue manager
- Configure the channel initiator which does queue manager to queue manager communications, and remote client application communication
- To encrypt and protect messages, configure Advanced Message Security
- To use File Transfer over IBM MQ, configure Managed File Transfer for z/OS .
- To use the administrative or messaging REST API, or the MQ Console to manage IBM MQ from a web browser, configure the mqweb server.
Some enterprises have thousands of queue managers in their environment. We need to consider your IBM MQ network now, and in five years time.
On z/OS, some queue managers process thousands of messages a second, and log over 100 MB a second. If you expect very high volumes you may need to consider having more than one queue manager.
On z/OS, IBM MQ can run as part of a queue sharing group (QSG) where messages are stored in the Coupling Facility, and any queue manager in the queue sharing group can access the messages. To run in a queue sharing group we need to consider how many queue managers we need. Typically, there is one queue manager for each LPAR. We might also have one queue manager to backup CF structures regularly.
Some changes to configuration are easy to do, such as defining a new queue. Some are harder, such as making logs and page sets bigger; and some configuration cannot be changed, such as the name of a queue manager or the queue sharing group name.
There is performance and tuning information available in the MP16 performance SupportPac .
Naming conventions
We need to have a naming convention for the queue manager data sets.
Many enterprises use the release number in the name of the load libraries, and so on. We might want to consider having an alias of MQM.SCSQAUTH pointing to the version currently in use, such as MQM.V900.SCSQAUTH, so we do not have to change CICS, Batch, and IMS JCL when we migrate to a new version of IBM MQ.
We can use a symbolic link in UNIX System Services to reference the installation directory for the version of IBM MQ currently in use.
The data sets used by the queue manager (logs, page sets, JCL libraries) need a naming convention to simplify the creation of security profiles, and the mapping of data sets to SMS storage classes that control where the data sets are placed on disk, and the attributes they have.
Note, that putting the version of IBM MQ into the name of the page sets or logs, is not a good idea. One day you might migrate to a new version, and the data set will have the "wrong" names.
Applications
We need to understand the business applications and the best way to configure IBM MQ. For example if applications have logic to provide recovery and repeat capability, then non persistent messages might be good enough. If we want IBM MQ to handle the recovery, then we need to use persistent messages and put and get messages in syncpoint.
We need to isolate queues from different business transactions. If a queue for one business application fills up, we do not want this impacting other business applications. Isolate the queues in different page sets and buffer pools, or structures, if possible.
We need to understand the profile of messages. For many applications the queues have only a few messages. Other applications can have queues build up during the day, and be processed overnight. A queue which normally has only a few messages on it, might need to hold many hours worth of messages if there is a problem and messages are not processed. We need to size the CF structures and page sets to allow for the expected peak capacity.
Post configuration
Once you have configured your queue manager (and components) we need to plan for:
- Backing up page sets.
- Backing up definitions of objects.
- Automating the backup of any CF structures.
- Monitor IBM MQ messages, and taking action when a problem is detected.
- Collecting the IBM MQ statistics data.
- Monitor resource usage, such as virtual storage, and amount of data logged per hour. With this we can see if your resource usage is increasing and if we need to take actions, such as setting up a new queue manager
- Plan your storage and performance requirements on z/OS
We must set realistic and achievable storage, and performance goals for the IBM MQ system. Use this topic help you understand the factors which affect storage, and performance.- Plan your page sets and buffer pools
Information to help you with planning the initial number, and sizes of our page data sets, and buffer pools.- Plan your logging environment
Use this topic to plan the number, size and placement of the logs, and log archives used by IBM MQ.Parent topic: Plan the IBM MQ environment on z/OS