| Author |
Message
|
| tleichen |
 Posted: Thu May 31, 2007 11:35 am Post subject: FAIL_IF_QUIESCING |
 |
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
With an increasing number of non-programmers doing programming (and some who just plain shouldn't), it has always been a pet peeve of mine when people write MQSeries applications and don't specify FAIL_IF_QUIESCING, where applicable. This got me thinking that since this is critical, why didn't IBM just make that inherent for all MQ API calls? Is there any good reason to have an API call not fail when the queue manager is quiescing? Any thoughts? 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
 |
| Michael Dag |
| Posted: Thu May 31, 2007 12:28 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
The only reason I can think of is to force the programmer to think of what to do when they get the FAIL_QUIESCE return code?
IBM hasn't always made the best default choices and once chosen it's hard to change the default behaviour... 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| tleichen |
| Posted: Thu May 31, 2007 12:49 pm Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
Perhaps. But I can't help thinking about the consequences when someone codes an MQGet with MQGMO_WAIT_UNLIMITED and does not specify MQGMO_FAIL_IF_QUIESCING. 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| cicsprog |
| Posted: Thu May 31, 2007 12:50 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
| Quote: |
| why didn't IBM just make that inherent for all MQ API calls? |
I pondered it and can't think of any situation. ANY return code should be handled by the application program!
I once had a old CICS Systems Programmer tell me "Coding is 5 percent business logic and 95 percent error handling". Hard to disagree with that statement from all the coding I've ever done. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu May 31, 2007 12:58 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| tleichen wrote: |
| Perhaps. But I can't help thinking about the consequences when someone codes an MQGet with MQGMO_WAIT_UNLIMITED and does not specify MQGMO_FAIL_IF_QUIESCING. |
I just tried to back track the logic, or what where you thinking morment... not that I agree... 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu May 31, 2007 1:14 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
On the same line, why does the plain MQ API allow you to set your own MsgId?
Because it's really not MQ's job to tell you how you should program.... if you want to code yourself into a twisty little mess of unconverted string data that fails mysteriously, and random appearing "duplicate" messages... that's your business.
Secondly, suppose that it was not obvious in the beginning that FAIL_ON_QUIESCE should be specified automatically. Now that, perhaps, it is "obvious" that it should be done... what impact does it have to change?
How many programs are going to be subtly and mysteriously affected by calls suddenly returning MQRCs that weren't coded for? And how the heck is the MQ team supposed to know the answer to this?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jsware |
| Posted: Thu May 31, 2007 1:19 pm Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
This has been discussed a number of times before. One reason would be if you are, for example, processing segments and you want to finish processing a logical message. You would therefore use fail-if-quiescing when you MQGET the first message in the segment, but then don't use this option until you try to start the next logical message.
There is an argument that the flags should be reversed so that you have a dont-fail-if-quiescing option, but you can't really change the defaults now without recompiling every program that uses MQ so take account of the change in default.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Jun 01, 2007 5:14 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| scottj2512 wrote: |
| One reason would be if you are, for example, processing segments and you want to finish processing a logical message. You would therefore use fail-if-quiescing when you MQGET the first message in the segment, but then don't use this option until you try to start the next logical message. |
good reason, now why didn't I think of that 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jun 01, 2007 12:51 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Michael Dag wrote: |
| scottj2512 wrote: |
| One reason would be if you are, for example, processing segments and you want to finish processing a logical message. You would therefore use fail-if-quiescing when you MQGET the first message in the segment, but then don't use this option until you try to start the next logical message. |
good reason, now why didn't I think of that |
Because you'd have made an LUW of the processing and rolled it back upon getting fail if quiescing...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jsware |
| Posted: Sat Jun 02, 2007 1:16 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| fjb_saper wrote: |
| Because you'd have made an LUW of the processing and rolled it back upon getting fail if quiescing... |
Perhaps I don't want to roll back a LUW and redo alot of processing if I can finish in a few ms and commit then let the queue manager shutdown. I would prefer to have the choice...
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| tleichen |
| Posted: Mon Jun 04, 2007 7:47 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| scottj2512 wrote: |
| Perhaps I don't want to roll back a LUW and redo alot of processing if I can finish in a few ms and commit then let the queue manager shutdown. I would prefer to have the choice... |
I suppose this is true. But to have this as the default gives an awful lot of control of the queue manager to individual user tasks, rather than to admins where you would normally think that control would be.
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jun 04, 2007 7:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| tleichen wrote: |
| scottj2512 wrote: |
| Perhaps I don't want to roll back a LUW and redo alot of processing if I can finish in a few ms and commit then let the queue manager shutdown. I would prefer to have the choice... |
I suppose this is true. But to have this as the default gives an awful lot of control of the queue manager to individual user tasks, rather than to admins where you would normally think that control would be. |
Now that depends entirely on where you think the control should be - application developers & system administrators have 2 clear yet opposing views on that! 
Following the example of scottj2512, it does make business & system sense to allow the application to finish a long running UOW and then stop rather than wait for an extended period while the rollback happens. It does also rely on the application being well enough designed to not hang around for ages, which may be the rock on which we founder. It's important not to administer in a bubble - if you can't bring the queue manager down ask the application people how long their process is going to be (and if they saw the email about the queue manager recycle!)
IMHO it's better to put 1st level control of when the application stops in the hands of the application developers. As administrators we have more than enough methods of ensuring a queue manager does eventually come down one way or the other.
It's also a good way of thrashing out poor application design and/or coding. No, thinking about it, thrashing is a good way of getting it fixed...  
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Mon Jun 04, 2007 6:40 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| tleichen wrote: |
| scottj2512 wrote: |
| Perhaps I don't want to roll back a LUW and redo alot of processing if I can finish in a few ms and commit then let the queue manager shutdown. I would prefer to have the choice... |
I suppose this is true. But to have this as the default gives an awful lot of control of the queue manager to individual user tasks, rather than to admins where you would normally think that control would be. |
At the risk of sounding like a rah-rah business motivational video, control should be with the business and that is typically where the problem is...different business applications have different requirements...some can handle the queue manager going out, some can't....only the business knows for sure. System folks tend to have more of a global impact overview, while application people tend to only have their own application needs in mind. In my experience, applications people don't fully understand the business needs outside of their area. I am a system guy and can see the arguement...if I want it out I want it out now not when some application agrees to it....but we are all working for the same company and in that case someone (usually a 'higher-up' gets to take the decisions about 'who wins' based on business risk.
Like it or not, the companies needs far outweigh the techies wishes in most cases.
Just my 2 cents.  |
|
| Back to top |
|
|
| jsware |
| Posted: Wed Jun 06, 2007 12:12 pm Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| tleichen wrote: |
| But to have this as the default gives an awful lot of control of the queue manager to individual user tasks, rather than to admins where you would normally think that control would be. |
I agree. I would hope that if the MQ labs could choose the defaults again they would have the default to fail if quiescing and have an option to not-fail-if-quiescing option for the rare occasion you might want to finish a LUW. But hey-ho as MichealDag said originally it difficult to change defaults once chosen
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
|
|
