| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| -lmqm and -lmqic ..question about these libs |
« View previous topic :: View next topic » |
| Author |
Message
|
| girlinusa2006 |
 Posted: Thu May 11, 2006 1:20 pm Post subject: -lmqm and -lmqic ..question about these libs |
 |
|
Novice
Joined: 09 May 2006
Posts: 24
|
Hi Folks,
I hope you can shed some light on a question/concern I have. Here is what I am trying to do:
I have created a process which
1) When it is brought up, it connects to this remote QM (B) , and puts a message in this remote queue ( B.QU).
2) Then it keeps on looking for a message in its local queue(A.QU).
3) If it finds a message in the local queue(A.QU) ( which is going to be placed by a remote process), it processes that message and stores it.
Now, I want to test this flow so I am trying to create a client which wud act as the other end of the above process. This client would initially keep looking for a message a message in its queue(B.QU). If it i receives a message , it then connects to the remote queue manager (A) and puts a diff message in that queue(A.QU).
But, when compiling this client, I have some confusion abut the use of libraries.
When I compile with -lmqic, I cannot connect to B.QU Qmanager to read the local messages. But when i compile with -lmqm , it is fine. But again, I guess I need to compile with -lmqic to write a message to the remote queue.
Can someone please clarify this for me? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu May 11, 2006 1:25 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You have two options.
1) Connect QM A and QM B using normal MQ channel pairs, and create a remote queue on A for B.QU and a remote q on B for A.QU. Then each app only connects to the local qmgr (A or B) using bindings (which is -lmqm). It can PUT to the remote qmgr but not GET.
2) Compile both your programs with -lmqic (the client libraries). Write your code to make TWO MQ connections, one as a client to A and one as a client to B. This will require you to not use MQSERVER, or to be able to update the environmental value of MQSERVER within your program. Most people would use MQCONNX here instead of MQCONN, because MQCONNX doesn't require environment variables to retrieve connection information. Each app can GET and PUT from local queues on either queue manager.
But if you do option 2, you've reimplemented the MCAs that move messages over normal MQ channels. And option 1 is the "best practices" approach, too.
_________________
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
|
|
|
|
