Avoid locking table at the start of a refresh

Currently  DB2 z/OS Remote agent will try to lock a table, apparently to obtain the head of logs position, just before starting a table refresh. Although the lock is immediately released, in some customer environments it very hard to obtain this lock. Customers end up with the error:
com.datamirror.ts.util.TsThread.run(TsThread.java:130)|Caused by: com.datamirror.ts.util.EnvironmentUserException A SQL exception has occurred. The SQL error code is '-913'. The SQL state is: 57033. The error message is: |[CDC][DB2 JDBC Driver][DB2]FAILED EXECUTION DUE TO DEADLOCK/TIMEOUT. REASON 00C9008E TYPE 00000D01|    at
com.datamirror.ts.customertable.db2z.dao.Db2zTablePropertiesDAO.lockTable(Db2zTablePropertiesDAO.java:89)|    at
com.datamirror.ts.scrapers.db2zscraper.Db2zLogConfig.getBookmark(Db2zLogConfig.java:104)|    at
com.datamirror.ts.scrapers.LogConfig.getStartBookMark(LogConfig.java:134)|    at
com.datamirror.ts.source.logcleanup.EarliestBookmarkTracker.setTableBookmarkToCurrent(EarliestBookmarkTracker.java:387)|    at
com.datamirror.ts.scrapers.history.ScrapedTableContextStorage.getAndProtectHeadOfLogForTable(ScrapedTableContextStorage.java:1687)|    at
com.datamirror.ts.scrapers.history.ScrapedTableContextStorage.captureVersionedTableStructure(ScrapedTableContextStorage.java:1544)|    at
com.datamirror.ts.scrapers.history.Db2zScrapedTableContextStorage.captureTableStructure(Db2zScrapedTableContextStorage.java:109)|    at
com.datamirror.ts.scrapers.history.ScrapedTableContextStorage.captureAndReturnTableStructure(ScrapedTableContextStorage.java:356)|    at
com.datamirror.ts.source.tablereader.TableReader.getCurrentBookMark(TableReader.java:458)|    at
com.datamirror.ts.source.tablereader.TableReader.beginTableRead(TableReader.java:166)|    at
com.datamirror.ts.source.tablereader.TableReader.beginTableRead(TableReader.java:121)|    at
com.datamirror.ts.source.replication.TableRefresher.refreshTable(TableRefresher.java:330)|    at
com.datamirror.ts.source.replication.MirrorComponent.doRefresh(MirrorComponent.java:374)|    at
com.datamirror.ts.source.replication.MirrorComponent.refreshTableSetForMirrorRefresh(MirrorComponent.java:3750)|    at
com.datamirror.ts.source.replication.MirrorComponent.evaluateRulesAndRefresh(MirrorComponent.java:2351)|    at
com.datamirror.ts.source.replication.MirrorComponent.startReplication(MirrorComponent.java:3397)|    at
com.datamirror.ts.source.replication.MirrorComponent.moderateForTheSource(MirrorComponent.java:456)|    at
com.datamirror.ts.source.replication.ModeratorBase$SourceDataChannelJob.execute(ModeratorBase.java:495)|    at
com.datamirror.ts.engine.component.PipelineThread.runThread(PipelineThread.java:217)|    at


This makes the refresh fail, and on this customer where they still have many occurrences of the DB2 LOAD utility makes the subscription abort many times and then they need to relaunch the refresh at times where the concurrent processes are not running. From what we gathered the concurrent processes use "persistent threads" which prevent this type of locks.

This is causing frequent issues in their replication environment.
 From discussions with development team, the Java agents have never used the lock to obtain consistency, and this lock to obtain the bookark should not be needed. The z/OS native agent apparently also removed the need for any lock for table refresh consistency (PTF PH38050), so this enhancement would put both agents at the same functionality level (althouth the cause for the lock seems to differ).
This would benefit all customers using the DB2 z/OS remote agent. Again, accordingly to internal discussions there are ways to obtain the same result without the lock