Locking Conflicts 

In R/3 on DB2 for OS/390, regular commits at a recommended frequency of at least one per minute also need to be included in read-only transactions and reports to release concurrently acquired locks on the database. This is because locks occur when reading buffer tables, cluster and pool tables. These tables are read using the Read Stability isolation level, and this sets shared locks to prevent simultaneous changes to tables.

Apart from timeouts and deadlocks, locking conflicts can cause failures of DDL (Data Definition Language) statements, such as CREATE, ALTER, and DROP, and slow down online reorganizations.

If a particular cursor needs to be open across commits, you can use the WITH HOLD option to preserve the cursor position.

You should execute the commits using Native SQL as follows:

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