| Author |
Message
|
| nik_iway |
 Posted: Wed Mar 15, 2006 1:39 am Post subject: MQ Questions |
 |
|
Centurion
Joined: 21 Jul 2005
Posts: 115
|
Hi Everybody,
I am having MQServer on Windows Machine and another on Mainframes, I established the connection between the 2 servers.
MQClients Installed on frontend Java and VB Connects to MQServer on the Windows.
MQClient Connects To MQServer on the Windows to put a Message and the message is routed to MQserver on Mainframes.
My Quesstion is that Wen i am retriving the Message from the MQserver on the Mainframes, i need an option to open Queue and retrive the message, if the message does not exists i need to lock the queue ... I dont want to browse the Queue repeatedly, If there is no message the queu must gets loked up, once the message arrives it needs to reopen and message must be retrived...
wat r the possible options in MQOPEN call and MQGET call to acheive it..
Thanking you
Regards
Nik |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Wed Mar 15, 2006 1:59 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
you can not lock a queue, but from what you wrote i assume you are looking for the get-wait.
your programm will sit on the empty queue sleeping, when a message arrives mq will wake up the program immediately. if the waittime expires without a message arriving then the program will get a 2033 - no message available, but it is up to you to go into get-wait again.
(there is also a infinite wait). anyway, if get-waiting you should also use the option "fail-if-quiescing" or any other mechanism that makes it possible for you to terminate the application.
other possibilities are to trogger the application on arrival of messages (trigger every, trigger first, ...) but that depends on your environment and application design.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Mar 15, 2006 3:56 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
You could open the queue with the option MQOO_INPUT_EXCLUSIVE. This would prevent any other app opening the queue while the app held it open.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Wed Mar 15, 2006 4:08 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi nik_iway,
The locking of the queue is not a good practice...trigger sounds much better as Mr Butcher said.
Is the application that is opening the queue scheduled ?
What will happen if the application crashes....how does it reconnect to QM ?
What is the actual requirement....
Regards. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Mar 15, 2006 5:26 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Quote: |
| The locking of the queue is not a good practice |
In whose opinion?
Just yours?
If the app crashes the queue will be closed by the agent on behalf of the app within 10 seconds. The app can reconnect and open the queue again.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Wed Mar 15, 2006 9:05 pm Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi Nigelg,
U seem to be taking it to heart 
The reason why I would not suggest a lock on queue is, if tomorrow you want to make an enhancement in the application, and this requires usage of the specified queue, you will have problems as everytime you try to connect, u'll find it locked....
Now I don't know about you, but for the projects and clients i've worked with, I would rather not use someting like this which will have me changing code all over the place....
Regards. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Mar 16, 2006 6:18 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Just to jump in here....I see nothing wrong at all with opening a queue as exclusive. If a new application comes along then it should use another queue. You have far worse issues (IMHO) sharing queues for no good reason. If you have a good reason then I could probably argue that the original 'locking' program could, potentially, need changing anyway to ignore the new messages that are getting dropped on the queue. 'Locking' also gives you a good way of isolating work.
Horses for courses.
 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Mar 16, 2006 8:26 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I view a queue as a container for logically related data that all requires the same work to be done.
That is, an application should basically do one thing to every message that comes in to the queue. Mind you, this can be a complicated thing - like for example "Transform all messages coming out of this large subsystem from their native XML format into the appropriate COBOL format". Different steps may happen to different messages - but it's still one function for one logically connected set of data.
Thus, I never see a reason for applications to share queues. And locking is only necessary when the application requires protected access to the queue while performing it's job.
But a locked queue can never be browsed by a management tool, so using locking can significantly increase the impact of issues with the application (you *have* to stop the application, rather than being able to copy the queue contents elsewhere and then clear the queue - if you need to clear a poison message for example).
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Mar 16, 2006 8:38 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
"locked queue" ... nice terminology .... in any case, if you do open queues for exclusive input, should that be something defined at the queue (defsopt/(no)share) or should the application specify it (MQOO_INPUT_EXCLUSIVE)....?
imho, it should be done at the queue definition level and not in the application, this way I don't need to make any appl changes when I need multiple instances of the application to handle the load....
_________________
-wayne |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Mar 16, 2006 9:44 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| jefflowrey wrote: |
| But a locked queue can never be browsed by a management tool... |
Jeff, from the APR manual:
| Code: |
MQOO_BROWSE
Open queue to browse messages.
The queue is opened for use with subsequent MQGET calls with one of the following options:
MQGMO_BROWSE_FIRST
MQGMO_BROWSE_NEXT
MQGMO_BROWSE_MSG_UNDER_CURSOR
This is allowed even if the queue is currently open for MQOO_INPUT_EXCLUSIVE.
|
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzak.doc/js02681.htm
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Mar 16, 2006 9:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It still can't be cleared.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
