| Author |
Message
|
| bruce2359 |
 Posted: Fri Jun 12, 2015 6:44 am Post subject: RANT: Least favorite defaults (initial values) |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
What are your least favorite MQ from-the-factory defaults (initial values)? What should they be? Why?
My least favorite are the _AS_Q_DEF kind. These allow sysadmins to override or undo what should have been set-in-concrete in the application code - message persistence, for example. These make problem-determination a pain.
_________________
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 |
|
 |
| fjb_saper |
| Posted: Fri Jun 12, 2015 6:50 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
How about queue manager creation defaults like log file size ?
I understand that until the mid 80s disk might have been considered an expensive storage but in these days of post modern ages, disk is cheap.
So why keep the low low setup ?? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Jun 12, 2015 7:01 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
the AS_Q_DEF values are mostly harmless. I guess the PERCISTENCE One causes most angst.
When I'm in my role as an MQ Developer I always make sure that I set the persistence of any message I write like the CCSID and in most cases the EXPIRY.
In my role as an MQ Architect/Admin/General Dogsbody, I have lost count of the number of times that sloppy programming (or just plain ignorance) has been the root cause of issued down the line. The CCSID is a prime candidate here.
My main gripes are at the QMGR level. IMHO the DLQ should not begin with SYSTEM. Plus understanding the reason codes for messages being put on a DLQ should he easier to obtain.
Generally a better understanding of the role the SYSTEM.DEFAULT.* Objects would really help a lot of so called MQ Admins.
Finally, isn't it about time that IBM defaulted to 1208 for any queue manager that is created on a distributed system? Having the defalt CCSID different on Windows and Unix platforms can be an real problem to find for those who have not encountered it before.
_________________
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 |
|
|
| bruce2359 |
| Posted: Fri Jun 12, 2015 7:34 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| smdavies99 wrote: |
Generally a better understanding of the role the SYSTEM.DEFAULT.* Objects would really help a lot of so called MQ Admins.
|
The name alone adds to the confusion. They are not really defaults. As an example, if the app MQOPENs a queue named 'fred' but the real queue name is FRED (upper-case), a novice might assume incorrectly that the SYSTEM.DEFAULT.LOCAL.QUEUE would be the 'default' destination for messages - definitely not the case.
IBM should have named them SYSTEM.TEMPLATE.* as these are used as templates to supply missing attribute values when creating a new object.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Sat Jun 13, 2015 6:01 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
One could argue the defaults should all be set to the smallest value possible, to force the MQ Admin to make a decision and not assume anything.
While I would be in favor of seeing Persistence As Queue Default going away, at the same time I want Expiry As Queue Default to be implemented.
I use SYSTEM.DEAD.LETTER.QUEUE for all my QMs. There is nothing magical about that queue, it is not used as a template for the creation of any other queues, and its logical to me that the System's Dead Letter Queue is called SYSTEM.DEAD.LETTER.QUEUE. Its a system queue. But if others think there is something to be gained by calling them DEAD.LETTER.QUEUE, or <QMname>.DEAD.LETTER.QUEUE, what's the harm in that.
Log Buffer Pages is long over due for a higher default as well as a higher max.
Without specific and precise rules to govern how large a log file should be made, IBM should just remove the option, make log files one size and one size only based on their special secret knowledge on what the best size is, and then just leave it up to us as to how many we want.
The Description field is horribly inadequately sized. Life would be easier if we could put a lot more info in there, or if queues were allowed to have metadata attached to them.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| exerk |
| Posted: Sat Jun 13, 2015 7:30 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| PeterPotkay wrote: |
| I use SYSTEM.DEAD.LETTER.QUEUE for all my QMs. There is nothing magical about that queue, it is not used as a template for the creation of any other queues, and its logical to me that the System's Dead Letter Queue is called SYSTEM.DEAD.LETTER.QUEUE. Its a system queue. But if others think there is something to be gained by calling them DEAD.LETTER.QUEUE, or <QMname>.DEAD.LETTER.QUEUE, what's the harm in that. |
I'd like to see that particular queue used for 'system-related' stuff only, in the same manner as event queues etc.
_________________
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 |
|
|
| tczielke |
| Posted: Sun Jun 14, 2015 2:17 pm Post subject: Re: RANT: Least favorite defaults (initial values) |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| bruce2359 wrote: |
| My least favorite are the _AS_Q_DEF kind. These allow sysadmins to override or undo what should have been set-in-concrete in the application code - message persistence, for example. These make problem-determination a pain. |
Another thing that is confusing on this topic is to have constants like MQPMO_RESPONSE_AS_Q_DEF that resolve to x'00000000'. The PMO is basically a 32 bit mask. To say you are explicitly setting something like MQPMO_RESPONSE_AS_Q_DEF in your application, but then not have that constant resolve to a specific bit in the bit mask is confusing.
In reality, it looks like MQPMO_RESPONSE_AS_Q_DEF is in effect when both the MQPMO_SYNC_RESPONSE and MQPMO_ASYNC_RESPONSE bits are not set in the PMO bit mask. So it really has nothing to do with MQPMO_RESPONSE_AS_Q_DEF, but the two "live" constants that actually map to bits in the bit mask.
To me, it would be more clear and straightforward if every constant that you can set in the bit mask would map to a specific bit in the bit mask.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jun 17, 2015 8:43 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The last default value that really torqued my nerves is MAXMSGL.
I'm really unhappy with it being set to 4k. Even 10k would be better. Basic storage size has grown enough that 4k is a too pessimistic limit. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jun 17, 2015 10:18 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| mqjeff wrote: |
| ...I'm really unhappy with it being set to 4k. Even 10k would be better... |
You do, of course, mean MB 
_________________
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 |
|
|
| smdavies99 |
| Posted: Wed Jun 17, 2015 10:36 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mqjeff wrote: |
The last default value that really torqued my nerves is MAXMSGL.
I'm really unhappy with it being set to 4k. Even 10k would be better. Basic storage size has grown enough that 4k is a too pessimistic limit. |
I've been using MQ for almost 16 years. In that time, I have never had to actually deal with messages that are greater than 1Mb. In old WBIMB Days we had to increase the message size to more than 4Mb because of the way the Config Mgr worked but now? No problemo
Maybe I'm lucky but This particular default is one of the ones I worry about the least. Sure there are sites that want to use multi Gb messages over HTTP. These should be taken out the back and done away with (humanely of course).
_________________
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 |
|
|
| mqjeff |
| Posted: Wed Jun 17, 2015 10:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| exerk wrote: |
| mqjeff wrote: |
| ...I'm really unhappy with it being set to 4k. Even 10k would be better... |
You do, of course, mean MB |
110, 111... whatever it takes. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Jun 18, 2015 4:50 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| mqjeff wrote: |
| exerk wrote: |
| mqjeff wrote: |
| ...I'm really unhappy with it being set to 4k. Even 10k would be better... |
You do, of course, mean MB |
110, 111... whatever it takes. |
Message size creep can be disastrous. 4MB is fine if your prod messages are 3MB, but over time they can slowly increase without being noticed. When they exceed 4MB for the first time all hell can break loose in a frantic effort to increase max lengths all over the place and replay the messages. Been there, done that. Significant cost to the business. We are now moving towards setting 100MB max length on all prod channels and critical queues. It exposes MQ to possibly very large messages, but its better than messaging interfaces failing because some arbitrarily low limit was exceeded.
_________________
Glenn |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 19, 2015 4:16 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| gbaddeley wrote: |
| Message size creep can be disastrous. 4MB is fine if your prod messages are 3MB, but over time they can slowly increase without being noticed. When they exceed 4MB for the first time all hell can break loose in a frantic effort to increase max lengths all over the place and replay the messages. Been there, done that. Significant cost to the business. We are now moving towards setting 100MB max length on all prod channels and critical queues. It exposes MQ to possibly very large messages, but its better than messaging interfaces failing because some arbitrarily low limit was exceeded. |
This. |
|
| Back to top |
|
|
|
|
