Queue Manager Alias

Queue aliases allowed us to refer to queues by more than one name. Queue Manager Aliases allow us to refer to queue managers by more than one name. We can define a Queue Manager Alias 'AliasQM' referring to the local queue manager as in Figure 55.

Figure 55. Defining a queue manager alias.


Messages addressed to 'AliasQM' will be routed to 'LocalQM', see Figure 56.

Figure 56. Addressing messages to a queue manager alias.


The redirection of the message by the alias is accompanied by a change in the 'destination queue name' from LocalQueue@AliasQM to LocalQueue@LocalQM. The fact that the message was originally put to the alias is completely lost. This can be seen by the labelling of the message route from the alias to the queue. Queue Manager Aliases are resolved very early during message resolution; in fact this is the first step that is performed.

Queue Manager Aliases are not much use in this scenario, but become very effective as part of more complex topologies. To complete the picture we can resolve both the Queue Manager Alias and the Queue Alias, see Figure 57.

Figure 57. Resolving the queue manager alias and the queue alias.


Here we put a message to LocalQueueAlias@AliasQM, and it is resolved first via the Queue Manager Alias, and then through the Queue Alias.

Resolution of queueManager aliases happens as soon as the request reaches a queue manager. The effect is to substitute the aliased string for the aliasing string. So for the first example above, as soon as the putMessage("AliasQM",....) call crosses the API, it is converted to a putMessage("LocalQM",....) call. This resolution is also performed when a message is put to a remote queue manager. On a remote queue manager the queue aliases on that queue manager are used, not those on the originating queue manager.

An alias can point to another alias. However, circular definitions have indeterminate results. An alias can also be made of the local queue manager name. This may not seem immediately useful, but it has a well defined purpose - it allows a queue manager to behave as if it were another queue manager. This pretence means that we can remove a queue manager entirely from the network, and by creating suitable queue manager aliases elsewhere we can allocate its workload to another queue manager. This feature is useful when modifying WebSphere MQ Everyplace network topologies, as servers, under the control of system administrators, can be moved, removed or renamed without breaking the connectivity of clients, which may not be so readily accessible.



© IBM Corporation 2002, 2003. All Rights Reserved