We have a problem when using DELETE ..WHERE CURRENT OF cursor. We get SQL error code -507 when running the DELETE statement.

Here is an example :

EXEC SQL DECLARE K01B CURSOR FOR
     SELECT * FROM KUNDE_TILLEGG
     WHERE  SYSTEMBANK  = :Z-SYSTEMBANK
       AND  KUNDENUMMER = :K01B-C.KUNDENUMMER
END-EXEC
EXEC SQL OPEN K01B END-EXEC.

EXEC SQL FETCH K01B INTO
COPY SIXK01B.
END-EXEC.

EXEC SQL DELETE FROM KUNDE_TILLEGG
         WHERE  CURRENT OF K01B
END-EXEC.

EXEC SQL CLOSE K01B END-EXEC.

The problem here is caused by the fact that the cursor is an "ambiguous cursor" - ie no FOR UPDATE clause has been specified on the DECLARE cursor.
See IBM documentation http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dsnapj13/2.2.1.1?SHELF=&DT=20060124094709&CASE= for more info on this.

To get round this you can either, update the DECLARE cursor to add the FOR UPDATE clause or change the BIND settings.

A query is ambiguous if there isn't a FOR UPDATE OF clause or something to indicate that the query is read only.  Queries are read only for a number of reasons.  They are marked as read only any time there is a join, a sort needs to be performed, subqueries are used, or data must be materialized to build the result set.  Sorting happens with clauses like UNION, ORDER BY, DISTINCT, and GROUP BY.  Data is materialized in certain views, table expressions, etc.  In all of these cases, DB2 no longer is pointing at the actual row in the location that provided the result.  It has had to continue reading from the location to build the result prior to returning any data.  In the absence of these clauses that make a query read only,
the FOR FETCH/READ ONLY clause can be added to make that distinction explicit.  Without a FOR clause or something to obviously mark the query as read only, the query is considered ambiguous.

For static SQL on the mainframe, the decision to make an ambiguous query read only and block fetch the cursor is indicated by the CURRENTDATA bind option ( DB2 UDB for z/OS V8 Application Programming and SQL Guide, The CURRENTDATA option ). 
CURRENTDATA=YES means that the query won't ever block fetch an ambiguous query (the cursor should always be pointing at the current data).
CURRENTDATA=NO means that you are happy to have a copy of the data the moment the block fetch happened.  You may not have the current data because another user  may have come right behind you and updated a row DB2 has already sent to you in the block of records.  You may not have actually fetched this record into your program yet so when you do fetch it you will not have the current data.

When using DRDA to access mainframe DB2 data from Mainframe Express, the control of ambiguous cursors is handled by the blocking protocol parameter of the DRDA connection.  When binding the default XDB Link packages you can change this parameter by selecting the "Bind" button of the "Modify Options" group in the "Bind Package" dialog.

That button brings up the "Bind Options" dialog.  In this dialog, you will see the "Block Protocol" drop down that offers "Single Row", "Limited Block", and "Forced Single Row".  "Limited Block", the default value, means that ambiguous cursors will block fetched. 
"Single Row" means that ambiguous cursors will not be block fetched.  "Forced Single Row" means that no cursor will ever be block fetched.