ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » MAXUMSGS

Post new topic  Reply to topic
 MAXUMSGS « View previous topic :: View next topic » 
Author Message
csmith28
PostPosted: Mon Dec 06, 2004 6:39 pm    Post subject: MAXUMSGS Reply with quote

Grand Master

Joined: 15 Jul 2003
Posts: 1196
Location: Arizona

In plain simple english what exaclty does this MAXUMSGS qmgr attribute do.

I searched the IBM WMQ .pdf and found some good information. I know that it has something to do with SyncPoints, Units of Work, Batches and it should be set to a low number like the default 10,000. Is that low?

10,000 seems like a lot to me.

My problem is I have a Server (AIX PSeries 4x4 5.1.0.0) running WMQ5.3.0.6 with just one MQManager that mysteriously and for no apparent reason, takes what I can only refrer to as a Network Nap.

One second everything is fine then:

BANG! BOOM! KAPLOW!

My my pager goes off, /var/mqm/qmgrs/MQMGR/error logs are filled with "AMQ9209 error occured receiving data from 'remote client application server'" over TCP/IP' and "AMQ9999 Channel ended abnormally" but, no .FDC files are created and there are no entries in the errpt that would indicate a failure of inetd or the NIC or.....................................anything.

These Naps last anywhere from less than 2 minutes to over 30 minutes.

The reason I ask about the MAXUMSGS attribute is that I have upped, reduced, tweaked or modified just about every other attribute on this MQManager under direction from IBM and I am desperate.

Could my MAXUMSGS setting have anything to do with this?

How about the CLWLLEN attribute?
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial.
Back to top
View user's profile Send private message
EddieA
PostPosted: Mon Dec 06, 2004 11:39 pm    Post subject: Reply with quote

Jedi

Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles

Quote:
I know that it has something to do with SyncPoints, Units of Work, Batches

Yes. It's the maximum number of messages that can be held, within a single syncpoint, without being commited by an application.

I very much doubt this has anything to do with your problem. Sorry.
Quote:
CLWLLEN(integer)
The maximum number of bytes of message data that is passed to the cluster workload exit.

Do you have a Cluster Workload exit. If not, then this is irrelevent as well.

Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0
Back to top
View user's profile Send private message
JasonE
PostPosted: Tue Dec 07, 2004 1:54 am    Post subject: Reply with quote

Grand Master

Joined: 03 Nov 2003
Posts: 1220
Location: Hursley

Just to add to Eddie's statement, as I understand it its the maximum number of uncommitted messages (ie messages under syncpoint but not committed) allowed across the whole qmgr, ie across multiple applications. So if one app puts 9999 messages under syncpoint and then goes to sleep, then other apps can only put 1...

Very unlikely to explain the problem you are seeing
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » MAXUMSGS
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.