Locking Conflicts in R/3 on DB2 for OS/390

If the R/3 System uses the database system DB2 for OS/390, even read-only operations require regular commits at least once per minute to ensure that any locks collected meanwhile on the database are released.

Locks are not only set by modifying transactions, but also by buffered tables, and SE>cluster and pool tables. The database system uses the "Read Stability" isolation level that uses "shared locks" to prevent table contents from being changed simultaneously.

Locking conflicts cannot only lead to timeouts and deadlocks but also to errors in DDL ( Data Definition Language) statements like CREATE, ALTER and DROP. What is more, they can slow down online reorganisation.

Should it be necessary to retain the position of the cursor beyond the time of commit, you can use the WITH HOLD option of the OPEN CURSOR statement.

The commits should be executed as database commits. You can use Native SQL as follows:

IF SY-DBSYS = 'DB2'.
EXEC SQL.
COMMIT WORK
ENDEXEC.
ENDIF.

You should include these database commits into all programs with long read operations.