| Author |
Message
|
| ydsk |
 Posted: Wed Mar 21, 2007 1:05 pm Post subject: Get Message Options - for a Reply msg |
 |
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
Hi,
My C++ client application does a PUT followed by a wait and then a GET.
C++ MQ client on Windows <---> MQ on AIX <--->MQ on mainframe / IMS bridge/IMS.
It's a request-response.
I am giving MQGMO_WAIT as an option before I do a GET.
Do I need to give MQGMO_FAIL_IF_QUIESCING as well before I do a GET ?
Can't I GET a message when the qmgr connection is quiescing ? If GET can complete successfully when it's quiescing I am thinking I can get rid of the option. I don't want the C++ appl to get a failure response when it's in a position to GET the actual response msg.
Any suggestions ?
Thanks.
ydsk. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Mar 21, 2007 1:08 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If the qmgr starts to quiesce before the msg arrives, then likely it will stay on the transmit queue on the remote side until the qmgr is back up.
If the qmgr starts to quiesce after the message has arrived, but before it's been committed, I believe that your MQGet will still receive it, and not get a Qmgr quiescing RC.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 21, 2007 1:54 pm Post subject: Re: Get Message Options - for a Reply msg |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ydsk wrote: |
Do I need to give MQGMO_FAIL_IF_QUIESCING as well before I do a GET ?
|
If you omit it, you need to provide some other mechanism to shut down your application when the queue manager wants to close. You also need to ensure that it's used every time, otherwise some poor admin (or worse still automated task)will issue an endmqm that will never end.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 21, 2007 2:51 pm Post subject: |
|
|
Guest
|
FAIL_IF_QUIESCING should be used on all MQ calls. It will advise the application (programmer) that a System Admin has issued the endmqm command (or equivalent).
The endmqm command has some options: -c is the controlled quiesce that allows all current MQCONected applicaions to run to completion, but no new MQCONNs; -i is the immediate quiesce that allows all in-flight MQ calls to complete, but no new calls; and -p (preemptive).
If the admin issues endmqm -c (the default), FAIL_IF_QUIESCING advises the programmer that the end is near, thus allowing the programmer to decide when/if to end the application gracefully (whatever that means). -c is good for applications; but possibly bad for admins. Example: computer room catches fire, -c doesn't force applications to end; admin and computer burn to a smoldering heap. |
|
| Back to top |
|
|
| ydsk |
| Posted: Wed Mar 21, 2007 3:26 pm Post subject: |
|
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
I see 2 possible response codes MQRC ( 1 for qmgr quiescing, and the other for qmgr stopping ).
What's the difference ? When do we get them ? Aren't they the same ?
Pls advise.
thnx.
ydsk. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Mar 21, 2007 3:29 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
qmgr stops after it's finished quiescing.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 21, 2007 4:33 pm Post subject: |
|
|
Guest
|
Not the same. Refer to the Application Programming Reference (and the Application Programming Guide) for info on how to code the MQ calls, the options, and the reason codes.
The programmer needs to check completion code for each MQ call. If MQCC_FAILED or MQCC_WARNING, the programmer must evaluate the reason codes appropriate to the call.
For all calls, MQCC_FAILED and MQRC_Q_MGR_QUIESCING will be returned to the programmer when the queue manager is quiescing. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 22, 2007 12:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ydsk wrote: |
I see 2 possible response codes MQRC ( 1 for qmgr quiescing, and the other for qmgr stopping ).
What's the difference ? When do we get them ? Aren't they the same ?
|
IIRC you'll only get the quiescing code if you specify the FAIL_IF_QUIESCING option, but you get the stopping code to indicate the queue manager has not serviced your request because it's been brought down.
The application response is the same - tidy up and close down it's all over, but with the quiesce mechanism the queue manager waits for your application to release the connection and end, giving you time to properly complete the unit of work. The stopping code indicates that the queue manager has been placed in immediate closedown (typically because the endmqm failed when an application failed to respond to the quiecse code) and the application has no further access to MQ. This can make the tidy up and close down process more awkward.
Hence my comment about the importance of a proper closedown mechanism if you don't use quiecse. It's important in that case your application is warned about the imminent queue manager closedown so that it has time to tidy.
As bruce2359 correctly points out, all this is laid out in the programming manuals in much greater detail than my limited summary.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Mar 22, 2007 12:52 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Use MQGMO_CONVERT as well to make your application work with messages from any platform (assuming they are MQFMT_STRING). |
|
| Back to top |
|
|
| ydsk |
| Posted: Fri Mar 23, 2007 10:00 am Post subject: |
|
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
Well,
My C++ client code isn't doing any syncpoints / unit of work because transactionality is taken care of elsewhere ( in the modules that call my C++ module).
All it does is PUT a request and then wait and GET a response.
I know C++ and MQ but didn't work with them together.
Here is an extract from Appl Prog Reference:
------------------------------------------------
MQGMO_FAIL_IF_QUIESCING
Force the MQGET call to fail if the queue manager is in the quiescing state.
------------------------------------------------
It looks like the GET is going to fail if the qmgr is quiescing though the reply msg is already available.
Why can't I get the message when it is available so that the request-reply processing is complete ? My question is: why should I specify the MQGMO_FAIL_IF_QUIESCING option and just fail when I am actually able to GET the message ?
I know it's a very good practice but it doesn't seem to make much sense to specify the option for GET in my case.
Thanks.
ydsk.
Last edited by ydsk on Fri Mar 23, 2007 10:10 am; edited 1 time in total |
|
| Back to top |
|
|
| ydsk |
| Posted: Fri Mar 23, 2007 10:07 am Post subject: |
|
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
It makes sense to specify MQPMO_FAIL_IF_QUIESCING for PUT and it sounds logical for the PUT to fail if the qmgr is quiescing.
But specifying the option for GET doesn't make sense to me at all ( this is in my case - not in general ).
I read the manuals but this issue isn't very clear to me.
Can somebody please explain.
thnx.
ydsk. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Mar 23, 2007 11:07 am Post subject: |
|
|
Guest
|
FAIL IF QUIESCING is advisory.
It makes sense that a program should know that the qmgr is quiescing. Your program can't know how (controlled, immediate, preemptive) the qmgr is quiescing, just that it is quiescing.
So, your program could do a MQGET with FAIL IF QUIESCING, discover that the qmgr is in fact quiescing; then, optimistically, do an MQGET without FAIL IF QUIESCING to get the message. If the sysadmin did a controlled quiesce (the default), the program would get the message and life would be good. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 23, 2007 1:56 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
Your program can't know how (controlled, immediate, preemptive) the qmgr is quiescing, just that it is quiescing.
|
I think if the queue manager has been instructed to close immediately, all you'll get is the stop reason code. The quiescing state is unique to the controlled closedown.
If you do go for optimistic get, do bear in mind that the closedown will wait until you release the connection. Factor in possible database or other delays as part of your design.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
