| Author |
Message
|
| zpat |
 Posted: Tue Jun 09, 2015 9:54 pm Post subject: |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
SInce MQ was first released, the typical MQ host is massively more powerful can can handle far more than the 100 (default) channels, the average message size is much higher than it was then etc.
Sorry, if you don't agree that these defaults catch out the untrained - but they do. Real PITA to change the log sizes for example afterwards.
IBM is full of propeller heads who think these things must be obvious - but then that has always been so - I suppose it generates work for us.
Sensible defaults really are important. The MQI default of having no message format is one of the annoying decisions. 
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed Jun 10, 2015 1:37 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| harsha8127 wrote: |
| Should i not consider the current flow and the requirment... |
Definitely...
| harsha8127 wrote: |
| If i think and keep 20000 depth and if the flow is more than that ...??? |
...then you will have sized maximum depth incorrectly.
| harsha8127 wrote: |
| ...or if i keep 100000 depth and if it is too more or the originally required is 20000 there will be load on the qmgr and the server...?? |
No, unless the queue fills.
| harsha8127 wrote: |
| ...That is why i have posted if there is any calculation or any way of thinking. |
And you have received many valid answers.
| gbaddeley wrote: |
| General guidance for maxdepth is the highest curdepth that would be experienced during the longest likely extended outage on the consuming app, plus an extra allowance. This might be 1 hour, 1 day or 1 week... |
That will give you a starting figure.
| gbaddeley wrote: |
| ...If the messages are large or high volume or persistent, the queue disk space and recovery log disk space will also need to be considered. |
So don't just focus on queue depth.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 10, 2015 4:10 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| zpat wrote: |
| exerk wrote: |
| All well and good provided the applications that put the original message honour the setting. |
"Persistence as per queue default", is the default MQI option, which for once is a helpful default.
Can't totally prevent stupid coding of course, but it helps avoid accidents. |
Helpful? Allow me to disagree.
IMHO, PERSISTENCE_AS_Q_DEF (persistence as defined at the queue) is one of the more troublesome "factory defaults," as it allows a system-admin to change a critical behavior of my application, namely: creating non-persistent messages, when the business case demands persistent messages. This one object attribute has been responsible for most of the "MQ lost my messages" client complaints.
"Factory defaults" cannot compensate for careless or inexperienced developers and system-admins.
_________________
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 |
|
|
| Vitor |
| Posted: Wed Jun 10, 2015 4:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| harsha8127 wrote: |
Does the Queue depth depends on the message size or length..  |
No - strictly number of messages.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 10, 2015 4:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| harsha8127 wrote: |
| zpat wrote: |
The default max depth of 5,000 is pretty out of date, I've made ours 50,000 (and also I make ours persistent by default).
|
What is "Out of date".Even for Verssion 9 after creation of queue the default is 5000 and it is not changed. That is why it is called "DEFAULT" |
I'm afraid I and others have hijacked your thread for a political discussion not related to your question. The term "out of date" was used by @zpat to underline that 5000 was set as a default back in the 1990s (when disc was expensive) and to indicate his view that it should be revised to reflect modern circumstances.
(Also if you're using MQ Version 9, send me a copy eh.....? )
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 10, 2015 4:26 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| Sorry, if you don't agree that these defaults catch out the untrained - but they do. Real PITA to change the log sizes for example afterwards. |
It's not so much a question of disagreeing - it's a question of what to do.
Observe this exchange:
| bruce2359 wrote: |
| zpat wrote: |
| exerk wrote: |
| All well and good provided the applications that put the original message honour the setting. |
"Persistence as per queue default", is the default MQI option, which for once is a helpful default.
Can't totally prevent stupid coding of course, but it helps avoid accidents. |
Helpful? Allow me to disagree.
IMHO, PERSISTENCE_AS_Q_DEF (persistence as defined at the queue) is one of the more troublesome "factory defaults," as it allows a system-admin to change a critical behavior of my application, namely: creating non-persistent messages, when the business case demands persistent messages. This one object attribute has been responsible for most of the "MQ lost my messages" client complaints. |
The persistence default can only be changed to one of two values and look at the debate it's generated. Think of what would happen trying to change the default value of an integer.
| zpat wrote: |
| Sensible defaults really are important. The MQI default of having no message format is one of the annoying decisions. |
I assume the is to indicate you know you're taking a crack at one of the few defaults logically defensible in the modern world.
| zpat wrote: |
| IBM is full of propeller heads who think these things must be obvious - but then that has always been so - I suppose it generates work for us. |
Or full of smart people who know better than to open a can of worms, and comfort themselves with the thought that retaining the values increases backwards compatibility.
I think we've all ranted enough about this, and should confine ourselves to advice directly connected to the very valid question posed by the OP, who must be wondering what's going on.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jun 10, 2015 4:52 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
No really, the lack of a default MQMD.Format value causes problems.
The entire point of MQ is to be cross-platform. But leaving out the MQMD.Format means messages don't get converted.
Thus taking away the biggest benefit of MQ.
At least one vendor has built a business based on modifying these defaults using the API crossing exit.
Whenever a vendor develops a product like that - it says to me that the IBM product has aspects that could be improved on.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 10, 2015 5:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| The entire point of MQ is to be cross-platform. But leaving out the MQMD.Format means messages don't get converted. |
The entire point is that MQ is cross platform and is not concerned with the payload of any message.
| zpat wrote: |
| Whenever a vendor develops a product like that - it says to me that the IBM product has aspects that could be improved on. |
It says to me that a lot of sites would sooner spend money on software than spend money putting standards & governance in place. I'd also wonder how many sites use such a product and fall foul of a COBOL copybook being mis-converted z/OS -> distributed (the most common "cross platform" situation).
For the second time I'll mention that this ranting is not relevant to the OP's question. Move your soap box to a new thread & I'll see you there.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jun 10, 2015 5:26 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Data conversion of the message data to the local codepage is a fundamental and a major feature of MQ, so I would have to disagree.
Most messages are string format and need conversion. I can't think of any site that would not be relying on this feature - unless there are places that really do only have one platform.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 10, 2015 5:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| Data conversion of the message data to the local codepage is a fundamental and a major feature of MQ, so I would have to disagree. |
All the features in MQ, and you pick conversion as a fundamental feature? In a piece of guaranteed store and forward software?
| zpat wrote: |
| Most messages are string format and need conversion. |
Unless the site has a mainframe with a significant COBOL code base.
| zpat wrote: |
| I can't think of any site that would not be relying on this feature |
- Any site with a mainframe
- Any site with IIB / TIBCO / webMethods / etc
3rd time - start a new thread. Moderation looms.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jun 10, 2015 5:41 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I can't be bothered to point out the errors in your statements. But as a moderator - you should try being moderate for once.
Rather than being determined to have the last word on a subject you claim does not belong here and to forbid me from responding at the same time!
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Jun 11, 2015 4:17 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| zpat wrote: |
SInce MQ was first released, the typical MQ host is massively more powerful can can handle far more than the 100 (default) channels, the average message size is much higher than it was then etc.
Sorry, if you don't agree that these defaults catch out the untrained - but they do. Real PITA to change the log sizes for example afterwards.
IBM is full of propeller heads who think these things must be obvious - but then that has always been so - I suppose it generates work for us.
Sensible defaults really are important. The MQI default of having no message format is one of the annoying decisions. |
IMHO, low values or blank values or restricted values for defaults tends to protect MQ from misuse, and it should make the designer consider appropriate use and settings for the features. A queue manager created and used with all defaults is NOT production ready or robust in many aspects.
_________________
Glenn |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Jun 11, 2015 10:04 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| gbaddeley wrote: |
| A queue manager created and used with all defaults is NOT production ready or robust in many aspects. |
Yet I see this all the time. Systems that were often installed by someone fresh of their MQ training (if they were lucky).
Any experienced MQ Architect/Designer will/should have a set of .mqsc scripts in their toolkit that 'fixes' the IBM defaults as soon as the QMGR is created.
By fixing, I mean things like
CCSID
Max Message Length for QMGR etc
Max Channels
Default Q* persistence
DLQ name (i.e. not starting with SYSTEM.)
etc etc
These should then become the standard set of defs for that site.
I regard these as important foundations for a successful QMGR setup.
I also spent half a day on this topic recently as part of a 2.5 day training course in MQ Installation for some of our Engineers.
Once done these generally get forgotten during the life of the QMGR because they 'just work'.
Just MHO though and others may disagree.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
