CICS MQ Listener (CPIL) serialisation of In-Only messages

CICS MQ Listener enhancement to serialise (or otherwise throttle) processing of "in-only" requests.

The CICS MQ Listener for web services (CPIL) currently schedules a new task immediately upon arrival of each message on a request queue. This is ideal behaviour for request-reply messages, but doesn't always suit the "in-only" message exchange pattern.

We have a situation where in-only messages usually arrive and are processed in near real-time. However, the requesting application also has a batch mode of operation, which can generate tens-of-thousands of messages on the request queue in a short period of time.

When requests arrive, CPIL dequeues each request and STARTs a new task (placing the request message in a container until the task starts processing). The batch-generated messages can result in thousands of tasks being started at once. Consequently we have a TranClass-limit on parallel execution of the started tasks (using an alias transaction instead of the default CPIQ). The TranClass typically has MaxAct(1).

This request is for an enhancement to the Listener, to throttle its processing rate such that a message is taken off the request MQ queue only when CICS is ready to process it. This would be preferable to the current situation in which messages are removed from the MQ queue, only to be placed in a TranClass queue in CICS. As the messages originate in an MQ queue, it would seem ideal to leave them in that queue until they can be processed.

We are operating in non-BTS mode.

This scenario was discussed with Mark Cocker on a recent visit, leading to this RFE. Thanks.