| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Help with CSQOREXX |
« View previous topic :: View next topic » |
| Author |
Message
|
| pav001 |
 Posted: Fri Feb 16, 2007 8:19 am Post subject: Help with CSQOREXX |
 |
|
Newbie
Joined: 15 Feb 2007
Posts: 2
|
Hi,
The system I am working on uses MQ to communicate with a Unix machine. Two channels have been defined for this, one for sending messages to Unix (channel1) and other for receiving (channel2). If I start CSQOREXX and display the properties for the channel1, it shows the transmission queue that is connected to this channel and is written into by the programs using MQPUT. But the properties of channel2 do not list the queue on which messages sent on channel2 from Unix are available. How can this be verified. The queue properties also do not give any indication to the channel it is connected to.
TIA!PAV |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Feb 16, 2007 8:25 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Applications are the sole decider of where a message goes.
If you have defined the transmit queue with the same name as the remote queue manager, then an application can send a message to *any* queue that exists on that remote queue manager - merely by setting both the queue name and the qmgr name in the MQOPEN call.
A channel is a pipe between two queue managers, it is not a pipe to a particular queue.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| pav001 |
| Posted: Fri Feb 16, 2007 10:54 am Post subject: |
|
|
Newbie
Joined: 15 Feb 2007
Posts: 2
|
On this system MQOPEN is done with MQHC-DEF-HCONN and the queue specified is the transmission queue defined on the mainframe. MQPUT uses the handle returned from this MQOPEN call. In both these places the Unix queue where the message should end up is not mentinoed. So how does the application decide to which queue on the other side should the message go?
TIA!PAV |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Feb 16, 2007 11:04 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If the Application does an MQOPEN on the XMITQ, then the application is doing the wrong thing.
That will execute the PUT directly against the XMITQ, and the message will not have an MQXH header, which will cause an erorr, and the message will likley go onto the DLQ when the channel starts. Or if it's an non-persistent message, then I think the MCA will discard it.
In order to send a message to a remote queue Q1 on QMGR2, when the app is connected to QMGR1, the application has these choices
1) MQOPEN a QREMOTE on QMGR1 that points to Q1, and don't specify a qmgr name
2) MQOPEN a QALIAS that resolves to a QREMOTE that points to a QREMOTE, and don't specify a qmgr name
3) MQOPEN a QCLUSTER of Q1, and don't specify a Qmgr name
4) MQOPEN Q1 and specify QMGR2 as the qmgr name
5) MQOPEN a QALIAS that resolves to Q1, and specify QMGR2 as the qmgr name
6) MQOPEN a QCLUSTER of Q1, and specify QMGR2 as the qmgr name to ensure the message goes to that specific instance
7) MQOPEN Q1 and specify the name of a Qmgr Alias as the QMGR name, where the qmgr alias points to QMGR2
and a few other options when multiple-hops are available.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
