Linked server to DB2 table locks
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)