Nein da gibts nichts. Wenn ihr einen Async-Job habt, sollte bei Sperren eine regelmäßige Prüfung des Asyncjobs stattfinden, ob der Job, der die Sperre ja setzt, noch aktiv ist.
Dafür gibts die Table-Function ACTIVE_JOB_INFO um das schnell auszuwerten.
Dies kann der Asyncjob ja alle x Sekunden prüfen, da ein QRCVDTAQ auch einen Timeout erlaubt.

Allerdings kann eine Satzsperre bei Fremdsystemen über einen längeren Zeitraum zu schweren Fehlern der daran hängenden anderen Apps führen. Bei der IBM i gibts einen Lock-Timeout, beim SQL-Server z.B. einen infinitive wait.
Konzeptionell, ich muss das sagen, ist das ein Schwachpunkt.

Generell ist zu empfehlen:
- Daten lesen ohne Sperre für die Anzeige
- Useraktion abwarten
- Daten lesen mit Sperre und die Voraussetzungen noch mal prüfen
- falls nicht OK dann Rollback mit Hinweis an den User
- falls OK dann verarbeiten und Commit.
Damit können andere machen was sie wollen, da auf Veränderungen zum Transaktionszeitpunkt reagiert werden kann.