Queue Manager Alias

Queue Manager Aliases enable you to refer to queue managers by more than one name.

Queue manager alias definitions apply when an application that opens a queue to put a message,
specifies the queue name and the queue manager name.

Queue manager alias definitions have three uses:

* When sending messages, remapping the queue manager name

* When sending messages, altering or specifying the transmission queue
* When receiving messages, determining whether the local queue manager is the intended destination for
those messages.

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.

Note:
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, you 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, the gateway queue manager must not contain an
instance of the EDINBURGH queue.