Potkay, Peter M (CTO Architecture + Engineering)
2013-09-27 19:07:52 UTC
Gimmie a vote if you think it's a good idea.
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=39722
I am looking for IBM to enhance the granularity of delivery options for MQ generated Event messages. While newer Event Message types such as Configuration Events get their own queue (SYSTEM.ADMIN.CONFIG.EVENT), legacy events share common queues. Authority, Inhibit and Start Stop Events all use the SYSTEM.ADMIN.QMGR.EVENT queue and there is no option to tune this. See the Use Case below on why one would want this capability.
One potential solution would be to create an Event queue for each Event type. To be backward compatible the new Event specific queues for legacy Event types could be defined as Alias queues resolving to the classic local queues. Potentially new Alias Queue SYSTEM.ADMIN.AUTH.EVENT could resolve to local queue SYSTEM.ADMIN.QMGR.EVENT. The change would be transparent to existing users, but would give me the ability to change the Alias Queue SYSTEM.ADMIN.AUTH.EVENT however I see fit, to allow me to send Authority Events and only Authority Events where I want.
Another solution would be to convert Eventing in MQ to a pure Pub Sub implementation. With a strong topic tree structure covering all Event types a user could subscribe to very specific Event types or all Event types. And multiple users could have overlapping subscriptions, each one to the queue of their choice. Events lend themselves to a Pub Sub model where multiple users, a single user or no users might be interested in a particular event.
Use Case:
Currently I do not have a robust tool to consume any and all event message as they arrive on event queues, parsing them to understand what the Event is. On my Edge Queue Managers I need Authority Events enabled, and we monitor the SYSTEM.ADMIN.QMGR.EVENT for q depth > 0. We get paged if there is an Authority Event on an Edge Queue Manager. But this precludes me from enabling any other events that share that same event queue unless I want to get paged for every other type of event that might use that queue (ah, no thank you). This is why we want the ability to send specific event message types to specific event queues.
Peter Potkay
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=39722
I am looking for IBM to enhance the granularity of delivery options for MQ generated Event messages. While newer Event Message types such as Configuration Events get their own queue (SYSTEM.ADMIN.CONFIG.EVENT), legacy events share common queues. Authority, Inhibit and Start Stop Events all use the SYSTEM.ADMIN.QMGR.EVENT queue and there is no option to tune this. See the Use Case below on why one would want this capability.
One potential solution would be to create an Event queue for each Event type. To be backward compatible the new Event specific queues for legacy Event types could be defined as Alias queues resolving to the classic local queues. Potentially new Alias Queue SYSTEM.ADMIN.AUTH.EVENT could resolve to local queue SYSTEM.ADMIN.QMGR.EVENT. The change would be transparent to existing users, but would give me the ability to change the Alias Queue SYSTEM.ADMIN.AUTH.EVENT however I see fit, to allow me to send Authority Events and only Authority Events where I want.
Another solution would be to convert Eventing in MQ to a pure Pub Sub implementation. With a strong topic tree structure covering all Event types a user could subscribe to very specific Event types or all Event types. And multiple users could have overlapping subscriptions, each one to the queue of their choice. Events lend themselves to a Pub Sub model where multiple users, a single user or no users might be interested in a particular event.
Use Case:
Currently I do not have a robust tool to consume any and all event message as they arrive on event queues, parsing them to understand what the Event is. On my Edge Queue Managers I need Authority Events enabled, and we monitor the SYSTEM.ADMIN.QMGR.EVENT for q depth > 0. We get paged if there is an Authority Event on an Edge Queue Manager. But this precludes me from enabling any other events that share that same event queue unless I want to get paged for every other type of event that might use that queue (ah, no thank you). This is why we want the ability to send specific event message types to specific event queues.
Peter Potkay
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html