Das Standardverhalten ist "Beim Lesen werden (im Modus *CHG bzw. Read Committed)..."
Wer Serializable verwendet, merkt sowas i.d.R. schon bei der Entwicklung, da fast grundsätzlich keine parallelen Transaktionen mehr möglich wären.

Was das Feststellen des Users angeht, so ist das tatsächlich ein Problem, da alle ODBC-Jobs (QZDASOINIT) mit dem Namen QUSER verheiratet sind.
Erst SQL setzt den tatsächlichen User per API (QSYSETPH), was über einen Joblog-Eintrag festgehalten wird.
Nun müsste man also nach dem Laden der Sperrinformationen (anderer Thread) per SQL, aus jedem Sperrjob das Joblog auslesen und nach dieser Nachricht (die ich im Moment jetzt nicht parat habe) scannen, die den User benennt.
Aber Achtung: Da QZDA-Jobs von anderen Verbindungen wiederverwendet werden, muss man diesbezüglich den letzten Eintrag im Joblog suchen.
Wenn man aber von der Anwendung sich mit einem sog. "App-User" anmeldet, hat man diesbezüglich leider verloren.

@Dieter
Seit wann werden Locks im Journal aufgezeichnet?
Na gut, bei offenen Transaktionen fehlt noch der Commit-Eintrag, also ist von einer Sperre auszugehen.