Integration
This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
Hi Sherif,
The 100 value is an optimal value for MQ, it could very well not be an optimal value for the application. Setting the optimal value as a hard limit is very likely to cause a large number of customers problems when they upgrade (a number of customers do this by creating new queue managers and so would pick up the new default) or bring new queue managers into service with existing applications.
Most customers wouldn't change their applications for something like this, they would just change MAXUMSGS back to 10000. So we would be back where we started.
Regards, Matt.
Hi Matthew,
Apologies. I am not clear how it would break the existing applications?
If you change it to be a default , this will apply to new queue managers only and it will come with only benefits as follows:
Applications which can work with it , will work with no issues
Applications that can't will detect the same and either decide to recode their applications or set it back to a higher value that suits them
Our concern about changing it before you change the default is that we would like this to pass quality assurance product side.
Could you please provide further details around this?
Thanks.
We are declining this idea. On z/OS having a maximum of 100 messages in a synchpoint gives good performance. However changing the value of MAXUMSGS to 100 is highly likely to break existing applications so we can't change the default. Instead applications should be coded with this advice in mind. Depending on what the application is designed to do, it may or may not be able to follow the guidance.
We will adjust documentation to make this clearer.
Hello,
Correct. That's a typo in the first line.
Later , I mentioned "the value of 100 applies..".
That's the correct ask to be the new default.
Apologies about the confusion caused.
Morag, I think that was a typo. We have a couple of places where we use 100 as an example "good" value, for example: https://www.ibm.com/docs/en/ibm-mq/9.2?topic=zos-tuning-your-queue-manager-mq which is echoed in MP1B.
Please supply where you found the IBM recommendation that there should be no more than 10 uncommitted messages? I personally don't believe that advice is correct and if it really is published out there somewhere, it should be corrected before anyone else believes it. There are many examples of quite normal behaviour where a transaction has more than 10 messages in it. When a channel moves a batch of messages the default batch size is 50. This means there could be 50 uncommitted messages while the batch is in flight - should that be changed too?