A reply-to queue alias definition specifies alternative names for the reply information in the message descriptor. The advantage of this is that you can alter the name of a queue or queue manager without having to alter your applications. Queue name resolution takes place at the sending end, before the message is put to a queue.
Normally an application specifies a reply-to queue and leaves the reply-to queue manager name blank. The queue manager fills in its own name at put time. This works well except when you want an alternate channel to be used for replies, for example, a channel that uses transmission queue 'QM1_relief' instead of the default return channel which uses transmission queue 'QM1'. In this situation, the queue manager names specified in transmission-queue headers do not match "real" queue manager names but are re-specified using queue manager alias definitions. In order to return replies along alternate routes, it is necessary to map reply-to queue data as well, using reply-to queue alias definitions.
In the example in Figure 16:
ReplyToQ='Reply_to' ReplyToQMgr=''
Note that ReplyToQMgr must be blank in order for the reply-to queue alias to be used.
DEFINE QREMOTE ('Reply_to') RNAME ('Answer') RQMNAME ('QM1_relief')
To prepare for the replies you have to create the parallel return channel. This involves defining:
DEFINE QLOCAL ('QM1_relief') USAGE(XMITQ)
DEFINE QREMOTE ('QM1_relief') RNAME() RQMNAME(QM1)
This queue manager alias terminates the chain of parallel return channels and captures the messages for QM1.
If you think you might want to do this at sometime in the future, arrange for your applications to use the alias name from the start. For now this is a normal queue alias to the reply-to queue, but later it can be changed to a queue manager alias.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
csqzae1028 |