Queue aliases enable you to refer to queues by more than one name. Queue Manager Aliases enable you 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 shown in the following diagram:
Messages addressed to 'AliasQM' are routed to 'LocalQM', as shown in the following diagram:
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 at the beginning of message resolution. Queue Manager Aliases are very effective as part of complex topologies
To complete the picture we can resolve both the Queue Manager Alias and the Queue Alias, as shown in the following diagram:
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 unpredictable results. An alias can also be made of the local queue manager name. This 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 MQe network topologies, because 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.