Possible Conflicting Locks 

If you are using the database system DB2 for OS/390, commits must take place at least once a minute, even if you are carrying out read only operations, in order to release any locks on the database that have occurred.

Locks occur here not only when using modifying transactions but also with consistent reading from buffered, cluster and pooled tables. The database system uses the isolation level Read Stability, which, with the help of Shared Locks, stops the table contents being changed while it is being read.

Conflicting locks can, like Time outs and Deadlocks, cause errors with DDL (Data Definition Language) statements, for example CREATE, ALTER and DROP. They can also slow down online reorganization.

If you need to keep the position of a cursor past the commit time then you can use the option WITH HOLD of the OPEN CURSOR statement.

The commits must be executed as database commits. You can use the following Native SQL for this.

IF sy-dbsys = 'DB2'.
  EXEC SQL.
    COMMIT WORK
  ENDEXEC.
ENDIF.

It is a good idea to build database commits like this into all programs with long read operations.