Wait interval for WFI

What is IBM’s opinion on implementing a “wait interval” for WFI?

Example of this functionality in action once implemented: having waited for the GU call to complete for the previously specified “WFI wait interval” (maybe possible to set and change during execution in the future by for example using the DL/I call SETO), WFI is interrupted and control is returned to the application program (its transaction defined with WFI=Y) with a return code specifying that the “WFI wait interval” has elapsed (status code other than QC is needed to be able to differentiate between “WFI wait interval” elapsed and PSTOP). The application program is released from WFI to perform other time dependent tasks before returning to the GU in the iteration which once again is performed to check if a message has arrived. The application program begins waiting again (due to WFI) until a message arrives or the previously set “WFI wait interval” has elapsed (whichever happens first), and so on.

Why is this functionality needed?
Answer: Repeatedly checking for messages is a waste of resources, e.g. CPU. WFI limits that problem though also prevents the transaction from performing other necessary time dependent tasks. For example, one of the most widely used financial transaction networks incorporate TCP/IP sockets in their official API. They have rules that dictate that they will close a socket if no messages are passed using the socket during a set time period. However, they also recommend users of their API to keep the sockets in a persistent state (since repeatedly reestablishing sockets will decrease performance). I.e. without the option to specify for how long WFI should last, sockets will be closed and thus performance compromised.

The functionality is provided by other “messaging technologies” for example, TCP achieves the functionality by the combination of options “blocking mode” and “receive timeout”, and MQ achieves it by providing the option “MQGMO_WAIT” and “WaitInterval”. But being forced to incorporate one of these other “messaging technologies” into an IMS based solution which already is a “messaging technology” in itself, only because IMS does not provide this particular functionality, makes the solution unnecessarily complex and more cumbersome to maintain. And that hurts.