IMS output message flood control

IMS has already a flood control for input messages. This covers the most common cases of message flooding in IMS. Even if mass insertion of output messages is very unusual, it is as ciritical to the system stability as mass insertion of input messages. Typically caused by application problems the IMS queues could get filled up with output messages within seconds. In the case an application by error inserts output messages in a loop this could also happen in milliseconds - much faster than any automation could react to prevent the system from an outage. The SEGNO option of the transaction definition helps in some of these cases but not in all. Even if the SEGNO option is being used to restrict the number of output message segments a transaction program can insert within a single scheduling for instance by 100 output message segments, a frequently used transaction program could very quickly cause an outage when every transaction inserts these 100 output message segments and then abends. Nevertheless misbehaviour of application programs is not the only reason which can result in an IMS message queue that gets filled up by output messages. Transaction programs which insert messages for other transaction programs that are not able to process these messages fast enough and printers which are not working are other samples.

Please add some output message flood control mechanism which prevents the system from an outage. The mechanism should include warning messages like those of the input message flood control. It would be good if IMS could identify which transaction program(s) inserts / are inserting output message that cannot be processed or delivered fast enough. When a defined critical threshold is being reached, these transaction program(s) could be quiesced until a value below a defined uncritical is being reached. This would allow the system to handle the situation itself in the case it is a temporary problem or the administrators to manually abdump and stop / pstop the quiesced transaction program(s) in the case they detected that the situation could not be resolved without additional activities. Alternatively IMS could abend those transaction program(s). The first described way to handle such situations would only lead into abends if manually activity is being done, but even if it would be the best way to handle it some of these situations, it would be not good in others. A lot of regions could be blocked by quiesced transaction programs and this could result in too much input messages being queued and in the end also in an outage because of a full message queue.

Please keep in mind that such a flood control mechanism should work both in queue sharing and in single system environments.