Publisher notification mechanism to alert publisher of first incoming subscription to one of its topics

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

Thank you for reviewing and responding to my RFE! In order to be sure I understand you correctly, I'd like some clarification on the two "pieces" you described:

Actually, let me start with a question about a comment you made in describing the second future feature (dynamic notification): Is it in fact true with current releases of WMQ that, for example, you could replace the SYSTEM.ADMIN.CONFIG.EVENT qlocal with a qalias of the same name and have the qalias resolve to a topic object? Since that is the impression I got from reading your description, I'll use that as an assumption in the following (please correct me if I'm mistaken):

The first future feature described was "subscription events". Is it safe to assume that the idea here is (initially, at least) that this mechanism would involve posting a PCF-formatted message to a system object (SYSTEM.ADMIN.SUBSCRIPTION.EVENT or some similar name) each time the queue manager becomes aware of a new subscription? If so, this could indeed be used to address the challenge we face (as described in the RFE) albeit a little inelegantly: the inelegance (as I see it) stems from the fact that any given publisher is only interested in the topics for which it is responsible, and "listening" to a subscription-events queue requires that the publisher process all subscription events whether relevant or not. Additionally, this would require tricking the queue manager into posting the subscription-event messages to a topic because otherwise the wrong publisher might consume any given subscription event message.

If this were the way subscription events were exposed, I would probably want to have a stand-alone subscription event consumer (or daemon, if you prefer) that decoded each PCF event message and posted a publication to a subscription-event topic whose fully qualified topic string would be the topic string indicated in the subscription event message, appended to a standard, queue-manager-wide topic string (probably associated with a topic object). To use an example associated with the example I used in the RFE, suppose we called the queue-manager-wide topic string we intend to use "NEW/SUBSCRIPTION". The first instance of a subscription to "Stocks/NYSE/IBM" would cause an event message to be posted to the subscription events system object; the stand-alone program would consume this message, extract the topic string ("Stocks/NYSE/IBM") and post a publication to the topic "NEW/SUBSCRIPTION/Stocks/NYSE/IBM". Our stock price publisher, upon start up, would have an active subscription to the wildcarded topic "NEW/SUBSCRIPTION/Stocks/#" and thus would be alerted to this subscription (via the publication by our stand-alone program based on the subscription event) as well as all relevant subscriptions, but never any irrelevant ones. An additional benefit of this approach is that PCF parsing logic would not have to be propagated to each publisher. On a side note, any program interested in all subscription events using this setup would simply subscribe to "NEW/SUBSCRIPTION/#".

I realize that for backward-compatibility reasons (if nothing else), the currently exposed classes of events (config, command, etc.) need to continue to be exposed via posting to a queue. However, I would think the notion of events fits better into a publish/subscribe paradigm (depending on the nature of the event, it is easy to imagine that more than one entity might have a practical, useful interest in it). Since you have not yet offered "subscription events" to the public, would you consider using topics (rather than a queue) as the default exposition mechanism? Even if you decided to publish all subscription events to a single topic ("SYSTEM/ADMIN/SUBSCRIPTION/EVENTS" or something similar, as opposed to constructing the topic for a subscription event from a common root and the topic string in the actual subscription itself), it would still enable a more dynamic model without customers having to play unusual games with system object names. By the way, if you were to consider using topics rather than queues for the currently available classes of events, couldn't you preserve current behavior by having a administered subscription to the event topic whose queue is the queue you currently use for posting those events?

My apologies if this writeup seems a bit long-winded. Any feedback will be most welcome! Thanks again!

Thank you for describing the problem you want to solve in this RFE. There are two possible future enhancements that when combined would solve your issue.

The first is subscription events - that is notification that a subscription has been created (similar to config events when a queue is created). This is something that we would like to provide in a future version of MQ.

The second is to make obtaining event notification a dynamic thing. Today to obtain event information you must enable events and read the notifications from a fixed queue name. Now today it is possible to make your event queues into a Qalias pointing at a topic, but that is still not very dynamic. Making this more dynamic is something that we would like to provide in a future version of MQ.

Putting these two pieces together would provide a solution to your problem, so making it something that we would like to provide in a future version of MQ by means of the above two pieces.

On an added note, for publish use-cases such as described here (publishers responsible for many closely related topics), this could also be helpful in managing the MQOPENs, since each topic would only need to be OPENed when there is active interest in it.