Additional DB2 MQListener Enhancements

We are about to see a ramp-up in the use of the DB2 MQListener in our production environments serving key application/business channels. We are requesting several enhancements that will improve usability and availability to the business process served by MQListener.

The following RFE's are submitted for your consideration:

1. Allow dynamic reloading/activation of the SYSMQL.Listener definitional rows.

Current application processes cannot tolerate the MQListener tasks being down, even for a short time. If we need to reload the SYSMQL.Listener definitions, before we can issue the recycle, we have to fail over the dependant application from the primary to secondary datacenter. This is a process that we do not want to employ unless it's absolutely necessary. The alternative we are proposing is to have a command that would either reload/reactivate all entries from SYSMQL.Listeners, or, have the ability to target a single listener definition and load/reload that one listener process. This would allow a non or minimally disruptive process to alter active listeners. In addition to the obvious example of adding a new listener to an up and running daemon, we might have the need to quickly change the NUMINSTANCES, WAITMILLIS, etc in order to respond to a capacity/performance issue.

Again, bottom line is to provide us with a non-disruptive process to tailor our DB2 MQListeners as need requires.

2. Change default behavior of listener daemon so that it stays up even if a SYSMQL.Listener entry has an error.

Our preference for daemon startup would be to ignore an incorrect listener definition and start normal with some sort of error message that identified the offending SYSMQL.Listener row. We had a recent production issue where this very issue (new SYSMQL.Listener row pointed at an incorrect MQ Instance) prevented the listener daemon from coming up and impacted all of the other ‘good' listeners. This would be very helpful especially in conjunction with item #1 above.