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.
Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - WebSphere
Product family - Integration
Product - IBM MQ
For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Connectivity and Integration
Product - IBM MQ
Another use case is that queues with PII or compliance-sensitive data are hosted on top of encrypted file systems whereas less sensitive queues are hosted on some other storage tier.
Sometimes applications flood a queue - may be due to a problem at the application. Limiting the MAXDEPTH or MAXMSGL attribute may not be helpful, when the messages are of variable length. In such cases it would be helpful, to be able to store several (groups of) queues of different locations - and so separate applications from others.
We are considering options for more flexibility in storage for a future release of MQ.
the isolation of the dead letter queue can minimize the impact of some incidents. Similarily, this feature would allow us to isolate queues prone to loading file systems from queues we don't want to be impacted by overloading. The only way to do so on distributed system is by creating several queue managers, which is not transparent for the applications (they have to manage their connections).Mapping queues to filesystems inside a single the queue manager would also be better for performance than using several queue managers.
It would also be useful to specify a max megabytes space on each "Storage Class" that is managed by MQ, so that each one does not require its own dedicated UNIX file system or Windows drive letter for space management done by the OS.
Great idea. Add Storage Class objects to distributed platforms, similar to WMQ on z/OS. The equivalent of a z/OS 'page set' would be a user specified directory, where queue files are created and managed as normal. The DEFAULT storage class would encompass current WMQ behaviour.