The example uses the WebSphere MQ for iSeries command language.
Figure 118. The message channel example for WebSphere MQ for iSeries
It involves a payroll query application connected to queue manager QM1 that sends payroll query messages to a payroll processing application running on queue manager QM2. The payroll query application needs the replies to its queries sent back to QM1. The payroll query messages are sent from QM1 to QM2 on a sender-receiver channel called QM1.TO.QM2, and the reply messages are sent back from QM2 to QM1 on another sender-receiver channel called QM2.TO.QM1. Both of these channels are triggered to start as soon as they have a message to send to the other queue manager.
The payroll query application puts a query message to the remote queue "PAYROLL.QUERY" defined on QM1. This remote queue definition resolves to the local queue "PAYROLL" on QM2. In addition, the payroll query application specifies that the reply to the query is sent to the local queue "PAYROLL.REPLY" on QM1. The payroll processing application gets messages from the local queue "PAYROLL" on QM2, and sends the replies to wherever they are required; in this case, local queue "PAYROLL.REPLY" on QM1.
Both queue managers are assumed to be running on iSeries. In the example definitions, QM1 has a host address of 9.20.9.31 and is listening on port 1411, and QM2 has a host address of 9.20.9.32 and is listening on port 1412. The example assumes that these are already defined on your iSeries system, and are available for use.
The object definitions that need to be created on QM1 are:
The object definitions that need to be created on QM2 are:
The connection details are supplied in the CONNAME attribute of the sender channel definitions.
You can see a diagram of the arrangement in Figure 118.
The following object definitions allow applications connected to queue manager QM1 to send request messages to a queue called PAYROLL on QM2, and to receive replies on a queue called PAYROLL.REPLY on QM1.
All the object definitions have been provided with the TEXT attributes. The other attributes supplied are the minimum required to make the example work. The attributes that are not supplied take the default values for queue manager QM1.
Run the following commands on queue manager QM1:
| QNAME | 'PAYROLL.QUERY' |
| QTYPE | *RMT |
| TEXT | 'Remote queue for QM2' |
| PUTENBL | *YES |
| TMQNAME | 'QM2' (default = remote queue manager name) |
| RMTQNAME | 'PAYROLL' |
| RMTMQMNAME | 'QM2' |
| QNAME | QM2 |
| QTYPE | *LCL |
| TEXT | 'Transmission queue to QM2' |
| USAGE | *TMQ |
| PUTENBL | *YES |
| GETENBL | *YES |
| TRGENBL | *YES |
| TRGTYPE | *FIRST |
| INITQNAME | SYSTEM.CHANNEL.INITQ |
| TRIGDATA | QM1.TO.QM2 |
When the first message is put on this transmission queue, a trigger message is sent to the initiation queue, SYSTEM.CHANNEL.INITQ. The channel initiator gets the message from the initiation queue and starts the channel identified in the named process.
| CHLNAME | QM1.TO.QM2 |
| CHLTYPE | *SDR |
| TRPTYPE | *TCP |
| TEXT | 'Sender channel to QM2' |
| TMQNAME | QM2 |
| CONNAME | '9.20.9.32(1412)' |
| CHLNAME | QM2.TO.QM1 |
| CHLTYPE | *RCVR |
| TRPTYPE | *TCP |
| TEXT | 'Receiver channel from QM2' |
| QNAME | PAYROLL.REPLY |
| QTYPE | *LCL |
| TEXT | 'Reply queue for replies to query messages sent to QM2' |
| PUTENBL | *YES |
| GETENBL | *YES |
The reply-to queue is defined as PUT(ENABLED). This ensures that reply messages can be put to the queue. If the replies cannot be put to the reply-to queue, they are sent to the dead-letter queue on QM1 or, if this queue is not available, remain on transmission queue QM1 on queue manager QM2. The queue has been defined as GET(ENABLED) to allow the reply messages to be retrieved.
The following object definitions allow applications connected to queue manager QM2 to retrieve request messages from a local queue called PAYROLL, and to put replies to these request messages to a queue called PAYROLL.REPLY on queue manager QM1.
You do not need to provide a remote queue definition to enable the replies to be returned to QM1. The message descriptor of the message retrieved from local queue PAYROLL contains both the reply-to queue and the reply-to queue manager names. Therefore, as long as QM2 can resolve the reply-to queue manager name to that of a transmission queue on queue manager QM2, the reply message can be sent. In this example, the reply-to queue manager name is QM1 and so queue manager QM2 simply requires a transmission queue of the same name.
All the object definitions have been provided with the TEXT attribute and are the minimum required to make the example work. The attributes that are not supplied take the default values for queue manager QM2.
Run the following commands on queue manager QM2:
| QNAME | PAYROLL |
| QTYPE | *LCL |
| TEXT | 'Local queue for QM1 payroll details' |
| PUTENBL | *YES |
| GETENBL | *YES |
This queue is defined as PUT(ENABLED) and GET(ENABLED) for the same reason as the reply-to queue definition on queue manager QM1.
| QNAME | QM1 |
| QTYPE | *LCL |
| TEXT | 'Transmission queue to QM1' |
| USAGE | *TMQ |
| PUTENBL | *YES |
| GETENBL | *YES |
| TRGENBL | *YES |
| TRGTYPE | *FIRST |
| INITQNAME | SYSTEM.CHANNEL.INITQ |
| TRIGDATA | QM2.TO.QM1 |
When the first message is put on this transmission queue, a trigger message is sent to the initiation queue, SYSTEM.CHANNEL.INITQ. The channel initiator gets the message from the initiation queue and starts the channel identified in the trigger data.
| CHLNAME | QM2.TO.QM1 |
| CHLTYPE | *SDR |
| TRPTYPE | *TCP |
| TEXT | 'Sender channel to QM1' |
| TMQNAME | QM1 |
| CONNAME | '9.20.9.31(1411)' |
| CHLNAME | QM1.TO.QM2 |
| CHLTYPE | *RCVR |
| TRPTYPE | *TCP |
| TEXT | 'Receiver channel from QM1' |