Very soon my client is going to migrate from 9.5 to 9.7. Good. One of the features I want to use is the currently committed. But not for the whole database. Just a few "selected" queries must come-up with an answer: straight through locks!

This should be possible. Here IBM DB2 9.7 for Linux, UNIX and Windows Information Center I read

You can explicitly set the cur_commit configuration parameter to AVAILABLE. Once you set this parameter, you need to explicitly request for currently committed behavior to see the results that are currently committed.

but is does not say HOW. I assumed that there would be a 5th value to the WITH clause (you know: select ... WITH UR). But that does not seem the case. Google looks away for me here

Anyone figured it out yet how to force a read-only query to read using cur_commit when you have your db cfg cur_commit set to available?

The doc "seems" to suggest it is a bind parameter or specified at statement prepare time (which suggests that use of the feature requires static SQL or dynamically prepared SQL):

"USE CURRENTLY COMMITTED or WAIT FOR OUTCOME are specified explicitly on the BIND or at statement prepare time."

Personally, I am very leery of the CURRENTLY COMMITTED, since the log data needed for this may have already been flushed to the active log on disk, or even the archive log. A well written application that finds the currently committed data in the log buffer probably does not need this feature, and a poorly written application will spend a lot of time searching the log files on disk which is going to be pretty slow. By using this feature, it seems to me that one would be encouraging poorly written application code by avoiding -911 errors (which provides immediate feedback to developers that the application is poorly written). I would consider using DB2_EVALUNCOMMITTED, DB2_SKIPDELETED, and DB2_SKIPINSERTED (and WITH UR) instead, and if -911 still occurs, fix the application code.

ConcurrentAccessResolution IBM Data Server Driver configuration keyword - IBM Database Driver

DB2Connection interface - IBM DB2 9.7 for Linux, UNIX, and Windows

I hear you. I've read more about this issue with the same 'tone' and I agree. That is why we are not going to activate this for the whole database. No, the database must act & react exactly the same as current (=v9.5). But there is 1 query and there quick responce is essential, even if you have to read past lock and come-up with 'old' values as an answer. A lock-wait is not acceptable, just for that 1 query.
So for that (java/jdbc) connection I am going to override the connection default and I am going to increase the logbufsz to avoid logreads.
That's the one! Thank you very much.