What Does Message MCH6206 Return Code 4 Really Mean

Resolving The Problem

Message MCH6206 return code 4 does not mean commit lock limit was exceeded.

A user had a job end with the following messages:

MCH6206  From program   #dbcommit        To program   QDBGETKY  
             Message . . . . :   Commitment control resource limit overflowed. Return code is X'04'.
   Cause . . . . . :   A resource limit in the commitment control function...has overflowed.
Return codes and their meanings follow:
0001  -- The lock limit has overflowed.
0002 -- The object list size has been reached.
0003 -- The maximum number of attached commit blocks allowed in the system has been reached.
0004 -- The reposition cursor data limit has been reached.
CPF5079  From program  QDBSIGEX  To program     QDBSIGEX  
                Message . . . . :   Commitment control resource limit exceeded for this job.
  Cause . . . . . :   The number of entries locked under commitment control in this job exceeded the lock limit ...  The lock limit for this job is 500000000.

The 'cause' text for message CPF5079 is misleading in the case of message MCH6206 return code 4. The cause text of message CPF5079 only refers to message MCH6206 return code 0001.

What does 'reposition cursor' mean and what limit was reached?

'Reposition cursor' is another way to say 'open file position.' Whenever a file is opened by a program, the operating system must locate a position within the file from which the program can then read, write, or update. InfoCenter explains how this works under commitment control. You can locate this information through the following path:
Database -> Commitment control -> Commitment control concepts -> How commit and rollback operations work:

Every time a file is opened, you have one position. Normally, you would not expect a single program to exceed the available open position slots per commit block. In r540, the unpublished number of slots is about 1,789,569.

For a program to use up this many slots, they must have opened and not closed the slot.


What can a user do to avoid this problem?

In this case, an RPG program was using commit control without issuing the commit before 'return'ing.

In order to avoid leaving the open position in the commit block, the RPG program would need to use SETONLR instead of RETURN. An alternative would be to issue COMMIT prior to the RETURN.