... immer diese Mythen:
@CLOSSQLCSR: F1 macht schlau!
Gibt an, daß SQL-Cursor implizit geschlossen, mit SQL vorbereitete
Anweisungen implizit gelöscht und Sperren, die mit LOCK TABLE
erfolgten, freigegeben werden. SQL-Cursor werden explizit
geschlossen, wenn der Benutzer die SQL-Anweisung CLOSE, COMMIT oder
ROLLBACK (ohne HOLD) ausgibt.
Schlußfolgerungen:
1.) das sind alles logische close Operationen, ob wirklich geschlossen wird, obliegt der Database Engine (kann sich also auch jederzeit ändern!)
2.) Wer mit Commit arbeitet, hat es hier einfacher!

@caching: Was die Database Engine wirklich cached, ist nicht dokumentiert und kann sich damit selbst mit einem PTF ändern. Applikationen dürfen nur auf dokumentierte Eigenschaften vertrauen, alles andere ist ein klassischer Kunstfehler.
Schlussfolgerungen:
1.) Wer alles mit SQL macht, hat mit den vom OP angesprochenen Sperren kein Problem.
2.) Wer Mix mit Altlasten hat, muss bei den Altlasten ansetzen. Der korrekte Weg dazu ist vor CLRPFM, RGZPFM und ähnlichem einen ALCOBJ CONFLICT(*RQSRLS) abzusetzen.

D*B