A more efficient way for CDC to process subscriptions which are behind in the Db2 logs

This is related to the CDC Db2 z/OS engine. The situation is multiple subscriptions that are behind, for example due to the subscriptions being stopped for several hours for technical reasons. We recently had 3 subscriptions that went down for more than 24 hours and one subscription that remained active and processing and advancing the CDC log cache. When the 3 subscriptions were restarted, the log cache no longer contained the needed log data as the active subscription had continued to advance the log cache. This was in a large 10 way Db2 data sharing group that is high volume. Upon restart of the 3 down subscriptions, each of the 3 subscriptions opened individual connections to Db2 requesting log data, which at that point was on archive logs that numbered over 2,000. We moved the archive logs from virtual tape to DASD to help speed the process, however, there was still the MAXRTU limit in play in Db2 on the number of archives that could be actively read. We have seen in the past in our testing environment when this happens, we can encounter what I will call an archive read deadlock from the subscriptions. For example, sub A needs to mount a member archive to continue to move forward; however sub B now has some of the drives as well so the archive needed by sub A can’t be mounted. At the same time sub B is needing an archive mounted but can’t because no drives are available because sub A has some of them but as mentioned can’t be moved forward. Plus, the process was requiring Db2 to read through the same 2,000+ archives 3 times, once for each subscription. There needs to be a more efficient way for CDC to process subscriptions which are behind where multiple subscriptions can leverage the same scraping process of the Db2 log data.