Linked server to DB2 table locks

Question

I have a problem with a SQL linked server connected to a DB2 database on an AS400 IBM iSeries.

I configured an ODBC connection from the ODBC Data Source utility. Once configured the ODBC, i created the LinkedServer and start using it for querying the DB2 database using SELECT * FROM OPENQUERY([LINKED_SERVER], 'SELECT * FROM [TABLE] FOR READ ONLY').

Once the query is executed, the DB2 table is locked and when the query ends the lock is not released. I temporarily solved the issue setting the ODBC connection type as read only and not as default.

Also all the DB2 tables that are used by the linked server are locked at every query even if they are not involved in the query.

Can someone help me figuring out how to not lock all the tables and set the linked server to read/write and not in read only mode. Like in the image, i executed a query only on SHPAV20F but locks are taken also for TTB03ACF and TTB0301P that are not involved in the query.

ODBC settings for commit mode is *CHG, PREFETCH for query data is enabled and LAZYCLOSE is disabled.

Answer 1

If by "table lock" you mean a "shared for read lock" (*SHRRD)... then it's likely that the cursor has been pseudo closed

Pseudo closed cursors are a key part of a performance optimization feature of IBM DB2 for i SQL. When an application closes a cursor, DB2 for i normally closes the cursor and closes the file, deleting the ODP (Open Data Path). If the application runs the same statement multiple times, each new execution requires a full open of the target file. The idea behind pseudo closed cursors is to not fully close the cursor and file but rather to cache the cursor for potential future use. The cursor is left in a soft closed (or pseudo closed) state. When the cursor is pseudo closed, the underlying file and ODP are left open. All record locks are released; however, a shared lock still appears on the file. DB2 for i can then reuse the cursor as needed without the overhead of a full open of the file. DB2 for i can also decide to hard close the pseudo closed cursor when needed.

They should not cause a problem unless you have a process that needs exclusive access, such as one that uses Clear Physical File Member (CLRPFM)

Such process should be avoided now-a-days, given the 24/7 nature of most business.

If you have to have an exclusive process, modify the process to request the locks to be released if needed... ALCOBJ OBJ((MYFILE *FILE *EXCL)) CONFLICT(*RQSRLS)