Better handling of message inserts agains stopped TPIPEs and transactions

When applications perform asynchronous callouts over a TPIPE and the distributed service, which should receive the messages isn't available it comes to a queuing in IMS. Depending on the amount of asynchronous callouts the message queue can get filled up due to this. As of today stopping the TPIPE doesn't prevent applications from queuing messages on this TPIPE. This is a huge problem in such situations - especially because it can be very hard to determine which applications are actually inserting messages against this TPIPE. 

One potential solution, which would allow to better handle such scenarios both from an administration as well as from a business point of view would be the following: 

When an application performs a CHNG call to a TPIPE as message destination IMS could somehow notice that and would then check on ISRT/PURG calls whether the TPIPE has been stopped. In the case the TPIPE has been stopped IMS would then return a non-blank status code to the application. There could be a parameter TPIPSTOP for the TPIPE with the following settings for a more flexible handling:

NOACTION (default): CHNG call would notice, that the output should be written on an OTMA TPIPE but it would also notice, that the TPIPE is configured with NOACTION and so no checking will be done on ISRT/PURG calls.

WARN: ISRT/PURG calls would check whether the TPIPE is stopped. If yes, an informational status code is being returned to the application, but the message is being queued. The application then can decide on whether to continue queuing messages or not.

FAIL: ISRT/PURG calls would check whether the TPIPE is stopped. If yes, an error status code is being returned and the message is not being queued.

I believe a similar setting would be very helpful for inserts against stopped transactions.

Please also take into account, that instead of performing a CHNG call an alternate TP PCB with a fix message destination could be used.