|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
MQ Code samples C++ |
« View previous topic :: View next topic » |
Author |
Message
|
Boomn4x4 |
Posted: Tue Dec 06, 2011 9:29 am Post subject: MQ Code samples C++ |
|
|
Disciple
Joined: 28 Nov 2011 Posts: 172
|
Can someone point me to where I can find code sample for C++.
Specifically, what I'm trying to do is to send a message to a remote queue, then get a reply back from that message. Is that even possible? Its my understanding from the documentation that I can never "get" from a remote queue, if so, how can I "get" a response from a remote queue on a remote queue manager? |
|
Back to top |
|
 |
Vitor |
Posted: Tue Dec 06, 2011 9:37 am Post subject: Re: MQ Code samples C++ |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Boomn4x4 wrote: |
Can someone point me to where I can find code sample for C++. |
Some come with the product; if they're not part of your install ask whoever did the install to add them. There are also samples on the Capitalware site through Roger's good graces.
Boomn4x4 wrote: |
Its my understanding from the documentation that I can never "get" from a remote queue |
Quite true.
Boomn4x4 wrote: |
if so, how can I "get" a response from a remote queue on a remote queue manager? |
The responding application needs to send it to you, using the information you supply (including potentially the fact that you're expecting a reply) in the MQMD.
The Intercommunication manual has a lot of good information on this. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
bruce2359 |
Posted: Tue Dec 06, 2011 10:00 am Post subject: Re: MQ Code samples C++ |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Boomn4x4 wrote: |
Its my understanding from the documentation that I can never "get" from a remote queue |
Yes, all mqgets are local.
The usual request-reply model presumes that the requesting application expects a reply message, and that the requesting app will name the reply-to-queue where the replying app is to send the reply.
The replying app should create a reply message, and send (mqput) it to the reply-to-queue named in the request message.
If your application is bound with the WMQ Client bindings, then the mqget call (and other mq calls) are shipped over the network to the qmgr named in the mqconn call. This complies with the 'all mqgets are local' rule. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
Boomn4x4 |
Posted: Tue Dec 06, 2011 10:18 am Post subject: Re: MQ Code samples C++ |
|
|
Disciple
Joined: 28 Nov 2011 Posts: 172
|
bruce2359 wrote: |
requesting app will name the reply-to-queue where the replying app is to send the reply.. |
So, since I am in a local/remote configuration, this would require a remote queue definition, transmission queue, and a local queue, on both the requester and replier along with a sender.receiver and a receiver.sender channel?
Considering I will need several hundred requestors all talking to a single replyer won't this result in an extremly difficult system to maintain?
If so, is "clustering" a better option? As I understand it, if I were to cluster all of the queues together, I could both send and get from any of the senders to the receiver and back without having to configure hundres of send/receive queues on both ends.... just on the sending end? |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Dec 06, 2011 10:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
You don't need a remote queue definition for each sender.
There does need to exist a path between each and every queue manager involved, and the replytoqueue name and or replytoqmgr name you specify needs to be resolvable using that path.
Even if you could do what you original wanted, you still have a very large configuration you would have to make. I.e. you either configure a route from each requestor, or you configure the replier with the qmgr connection information of each requestor.
Bottom line, there are a few different ways to accomplish this, but the requester always needs to indicate where the reply should be sent, and there needs to exist a path to that destination from the replier/server's queue manager. |
|
Back to top |
|
 |
Vitor |
Posted: Tue Dec 06, 2011 10:28 am Post subject: Re: MQ Code samples C++ |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Boomn4x4 wrote: |
So, since I am in a local/remote configuration, this would require a remote queue definition, transmission queue, and a local queue, on both the requester and replier along with a sender.receiver and a receiver.sender channel? |
Yes.
Boomn4x4 wrote: |
Considering I will need several hundred requestors all talking to a single replyer won't this result in an extremly difficult system to maintain? |
Only if all of these requestors are using different queue managers. In which case maintaining the system will be a problem second only to finding money to pay the IBM license fees.
You only need connectivity (channels & transmit queues) between the queue managers involved. If the applications needs the reply to be on a unique queue (rather than a unique reply on a common queue) have the requesting application create one.
Boomn4x4 wrote: |
If so, is "clustering" a better option? As I understand it, if I were to cluster all of the queues together, I could both send and get from any of the senders to the receiver and back without having to configure hundres of send/receive queues on both ends.... just on the sending end? |
Clustering doesn't break the "only get from local" rule. An application can only get from a queue local to the queue manager to which it's connected. Even if the queue manager does participate in a cluster.
Clustering is worth considering if you have a significant number of queue managers in your mix, or you're looking ahead to the day when there will be more than one replying application to increase throughput. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
bruce2359 |
Posted: Tue Dec 06, 2011 11:05 am Post subject: Re: MQ Code samples C++ |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Boomn4x4 wrote: |
Considering I will need several hundred requestors all talking to a single replyer won't this result in an extremly difficult system to maintain? |
No, not at all. A single replying app can serve many (dozens, hundreds) requesting apps. This is because the requesting app names the reply-to-queue and reply-to-qmgr in the request message MQMD.
Of course, there will need to be a path (channel, transmit queue, listener) from requesting qmgr to replying qmgr; and a path from replying qmgr back to requesting qmgr. These are one-time admin activities. These channels can be shared by other applications, as well. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
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
|
|
|
|