CONCURRENTACCESSRESOLUTION (USECURRENTLYCOMMITTED) - missing UPDATE support

For a new application we decided to use BIND option "CONCURRENTACCESSRESOLUTION(USECURRENTLYCOMMITTED)". In this case we didn't expected to run into a timeout for a SELECT statement, but received the following error:

DSNT408I SQLCODE = -911, ERROR: THE CURRENT UNIT OF WORK HAS BEEN ROLLED BACK DUE TO DEADLOCK OR TIMEOUT. REASON 00C9008E, TYPE OF RESOURCE 00000302, AND RESOURCE NAME AWAD0A70.AWAS0AQ0.X'000001C4'
DSNT418I SQLSTATE = 40001 SQLSTATE RETURN CODE
DSNT415I SQLERRP = DSNXRRC SQL PROCEDURE DETECTING ERROR
DSNT416I SQLERRD = 112 13172746 13172878 13813475 -1010298875 536870912
SQL DIAGNOSTIC INFORMATION
DSNT416I SQLERRD = X'00000070' X'00C9000A' X'00C9008E' X'00D2C6E3' X'C3C81005' X'20000000' SQL DIAGNOSTIC INFORMATION

When searching DB2 documentation we found, that UPDATE is not supported.
USECURRENTLYCOMMITTED: Specifies that when a read transaction requires access to a row that is locked by an INSERT or DELETE operation, the database manager can access the currently committed row, if one exists, and continue to the next row. The read transaction does not need to wait for the INSERT or DELETE operation to commit. This clause applies when the isolation level in effect is cursor stability or read stability.

Because our application is doing lots of more UPDATE statements than INSERT or DELETE, this feature is relatively useless without UPDATE support.

By the way, DB2/LUW does have full support USECURRENTLYCOMMITTED:
Specifies that the database manager can use the currently committed version of the data for applicable scans when it is in the process of being updated or deleted. Rows in the process of being inserted can be skipped.

DB2/zOS should also support USECURRENTLYCOMMITTED, even if the lock is set through a corresponding UPDATE statement.