| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Determine best value for MAXUMSGS |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Thu Jul 08, 2010 3:47 pm Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
MAXUMSGS is defined or referred to in a variety of places (APG, Intercommunications, MQSC Ref.)
From MQSC Ref., DEFINE/ALTER QMGR:
MAXUMSGS(integer)
The maximum number of uncommitted messages within a syncpoint.
This is a limit on the number of messages that can be retrieved, plus the
number of messages that can be put, within any single syncpoint. The limit
does not apply to messages that are put or retrieved outside syncpoint.
The number includes any trigger messages and report messages generated within the same unit of recovery.
Be aware that reducing the value of MAXUMSGS may cause problems to
existing applications and queue manager processes, such as clustering on
z/OS, if they are already using a higher value.
Specify a value in the range 1 through 999 999 999.
From APG:
The maximum number of messages within a unit of work can be controlled by the DEFINE MAXSMSGS command on z/OS, or by the MAXUMSGS attribute of the ALTER QMGR command on other platforms.
---------------------------------------------------------------------------
Unless I've completely lost my mind (a different subject altogether), MAXUMSGS at the qmgr sets the max for each individual single UofW, and NOT collectively for all concurrent UofWs.
So, with MAXUMSG(100), any number of concurrent apps can each individually get/put up to 100 messages in their UofWs.
_________________
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: Thu Jul 08, 2010 6:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Thanks for setting me straight there guys.
For the curious here is the v6 link
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| cicsprog |
| Posted: Fri Aug 13, 2010 7:35 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
Be aware that reducing the value of MAXUMSGS may cause problems to
existing applications and queue manager processes, such as clustering on
z/OS, if they are already using a higher value.
Specify a value in the range 1 through 999 999 999.
Boy is that true. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Aug 13, 2010 10:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Failure to understand both application design and qmgr administrative settings can lead to intermittent or catastrophic failures; and this is not limited solely to WMQ on z/OS.
Many (most) of the failures I've encountered have been sysadmins who believed that they were conserving on some system resource, like CPU, disk space or central storage.
_________________
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 |
|
|
| cicsprog |
| Posted: Fri Aug 13, 2010 11:57 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
A REFRESH CLUSTER has been the problem child where the black box of CLUSTER subscription processing has caused the MQM to exceed the 10k default on Max uncommitted messages. And, causing repostitory queue problems.
I haven't seen this type of problem for some time. So, defect might have played a hand in it. However, if I knew of some sort of CLUSTER wide change, I'd probably increase this value prior to the change. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Aug 13, 2010 1:16 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
PubSubSyncPoint (MQLONG)
Whether only persistent messages or all messages are processed under syncpoint.
The value is one of the following:
MQSYNCPOINT_IFPER
This makes the queued publish/subscribe interface receive non-persistent messages outside syncpoint. If the daemon receives a publication outside syncpoint, the daemon forwards the publication to subscribers known to it outside syncpoint.
This is the default value.
I haven't done any research, but I'm thinking that repository updates might also in be syncpoint (on z).
_________________
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 |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
