This topic explains, in detail, the concept of message routes and how to use them with MQe.
Several features of MQe allow the routing of messages to be altered dynamically. However, you need to ensure that there are no 'in doubt' messages that would be affected by the change. If a message is put with a non-zero confirm ID, and then the MQe network topology is changed to alter the routing of the subsequent confirmGetMessage call, the unconfirmed message will not be found. MQe protocol treats a failure to confirm a put as an indication that the put message has been confirmed already, and therefore assumes success. This could leave an unconfirmed message on a queue, which represents a loss of a message, and therefore breaks the assured delivery promise.
Since MQe uses the same two step process to assure delivery of asynchronously sent messages, regardless of whether a zero or non-zero confirmId is used, changing the network topology can break the assured delivery of asynchronous message sends.
The topics within Network topologies and message resolution use a consistent notation for illustrating the resources. This allows the areas of specific interest to be shown prominently, while the less relevant parts of a system can be hidden. This is easier to show with a diagram:
The following diagram shows the same resources in the 'dispersed' form:
The line with a diamond shape shows that the queue manager is the child of the host. This preserves the parent/child relationship from the tree, which would otherwise be lost by separating the elements.