Home

 

Queue-manager aliases

 

The concept of queue-manager aliasing is described in detail in the WebSphere MQ Intercommunications book.

Queue-manager aliases, which are created using a remote-queue definition with a blank RNAME, have four uses:

Remapping the queue-manager name when sending messages

A queue-manager alias can be used to remap the queue-manager name specified in an MQOPEN call to another queue-manager. This can be a cluster queue manager. For example, a queue manager might have the queue-manager alias definition: 
DEFINE QREMOTE(YORK) RNAME(' ') RQMNAME(CLUSQM)

This defines YORK as a queue-manager name that can be used as an alias for the queue manager called CLUSQM. When an application on the queue manager that made this definition puts a message to queue manager YORK, the local queue manager resolves the name to CLUSQM. If the local queue manager is not called CLUSQM, it puts the message on the cluster transmission queue to be moved to CLUSQM, and changes the transmission header to say CLUSQM instead of YORK.

This does not mean that all queue managers in the cluster resolve the name YORK to CLUSQM. The definition applies only on the queue manager that makes it. To advertise the alias to the whole cluster, we need to add the CLUSTER attribute to the remote-queue definition. Then messages from other queue managers that were destined for YORK are sent to the queue manager with the alias definition and the alias is resolved.

Altering or specifying the transmission queue when sending messages

This method of aliasing can be used to join a cluster to a non-cluster system. For example, for queue managers in the cluster ITALY to communicate with the queue manager called PALERMO, which is outside the cluster, one of the queue managers in the cluster must act as a gateway. From this queue manager, issue the command: 
DEFINE QREMOTE(ROME) RNAME(' ') RQMNAME(PALERMO) XMITQ(X) CLUSTER(ITALY)

This is a queue-manager alias definition, which defines and advertises ROME as a queue manager over which messages from any queue manager in the cluster ITALY can multi-hop to reach their destination at PALERMO. Any message put to a queue opened with the queue-manager name set to ROME in the open handle, is sent to the gateway queue manager, where the queue manager alias definition was made. Once there, it is put on the transmission queue X and moved by conventional, non-cluster channels to the queue manager PALERMO.

The choice of the name ROME in this example is not significant. The values for QREMOTE and RQMNAME could both be the same.

Determining the destination when receiving messages

When a queue manager receives a message, it looks in the transmission header to see the name of the destination queue and queue manager. If it has a queue-manager alias definition with the same name as the queue manager referenced, it substitutes the RQMNAME from its definition for the queue manager name in the transmission header.

There are two reasons for using a queue-manager alias in this way:

  • To direct messages to another queue manager

  • To alter the queue manager name to be the same as the local queue manager

Using a queue manager as a gateway into the cluster.

This enables workload balancing for messages coming from outside the cluster.

Suppose you have a queue called EDINBURGH on more than one queue manager in the cluster, and you want the clustering mechanism to balance the workload for messages coming to that queue from outside the cluster.

A queue manager from outside the cluster needs a transmit queue and sender channel to one queue manager in the cluster, which is called a gateway queue manager. To take advantage of the default workload balancing mechanism, one of the following must apply:

  • The gateway queue manager must not contain an instance of the EDINBURGH queue.

  • The gateway queue manager specifies CLWLUSEQ(ANY) on ALTER QMGR.

  • The EDINBURGH queue on the gateway queue manager specifies CLWLUSEQ(ANY).

For an example of this see Putting from a queue manager outside the cluster - alternative techniques

 

Parent topic:

Using aliases and remote-queue definitions with clusters


qc10790_


 

Home