Integration

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:

Post your ideas

Start by posting ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,

  1. Post an idea

  2. Upvote ideas that matter most to you

  3. Get feedback from the IBM team to refine your idea

Help IBM prioritize your ideas and requests

The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The offering manager team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.

Receive a notification on the decision

Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.

If you encounter any issues accessing the Ideas portal, please send email describing the issue to ideasibm@us.ibm.com for resolution. For more information about IBM's Ideas program visit ibm.com/ideas.

Status Future consideration
Created by Guest
Created on Mar 26, 2018

MQ Application Activity Trace - Filtering by Queue Name

RFE 55753 allows additional options for controlling the activity events produced. However, while mentioned, tracking by queue was not part of the implementation. Filtering by specific queue name is vital to any production tracing environment.

In this case, other trace events which may not be known can be omitted. That is, when tracing by queue, only events between MQopen and MQclose for that queue are required. For example, MQConnect is not relevant to this request nor requests to other queues. The key business objective is to determine who created the message and who read it. As such, it could be implemented as a post collection phase when being written to the buffer for processing, even though at an increase in overhead, some messages would be collected and discarded as not relevant.

The option should be available for both mqat.ini and subscriptions.

Idea priority Medium
Use Case
The use case is simple. Someone asks, what puts and gets were done to the ACCOUNT.QUEUE today? While this seems straight forward enough, in the current model (assuming no dedicated channel to the ACCOUNT.QUEUE), the first option is to trace all applications that you suspect put and get messages to it. In many cases, the sending and receiving applications might not be known. In this case, the only option is to trace every application. This results in a lot of data being reported that is not needed. In other cases, the application may not be unique, such as older MQ client applications or broker flows, etc. Again, there is need to track a lot of different applications. And of course, if you don't include the right one, you won't know which ones you needed since the result is no data.
RFE ID 118098
RFE URL
RFE Product IBM MQ