Make an new parameter to MQ-channel-definitions defining minimum-MQ-GET-WAIT-time

Many decentral MQ-applications are coded in Spring and Spring has a default MQ-GET-WAIT-time of one second, which decentral application-programmers typically don't worry about, but this relatively small MQ-GET-WAIT-time can cause a lot of CPU-overhead in the MQ-CHIN-task, especially when the application-programmer has set up an excessively high number of parallel sessions. Many installations have coded an MQ-channel-receive-exit to increase the MQ-GET-WAIT-time to prevent the high CPU-usage in the MQ-CHIN-task.
Note that a higher MQ-GET-WAIT-time will typically result in a faster (or absolutely not slower) response to the MQ-applications, as the GET-WAIT-request is expedited as soon as an MQ-message is received, when you are staying waiting ready for a MQ-message to arrive. 
Instead of many installations coding their own MQ-channel-receive-exit, it would make sense that IBM added a new optional parameter to MQ-channel-definitions: minimum-MQ-GET-WAIT-time to make it possible to overrule the MQ-GET-WAIT-time from the calling MQ-application.
Note that it will only make sense to use this new parameter on MQ-channels with characteristics as described above.   
Also note that other MQ-applications than MQ-applications coded using Spring can have the characteristics described above, Spring is just a typical example.