The condition where this can occur is as follows:
1) z/OS V1R12
2) Loopback subscriptions (DB2z to DB2z on the same system) using TCPIP FastPath
3) Large volume of data to be replicated.
User will see message in the DB2 log
DSNJ031I -DTVB DSNJW001 WARNING - UNCOMMITTED UR
HAS WRITTEN 200000 LOG RECORDS -
CORRELATION NAME = <CDCZstarted task name >
CONNECTION ID = DB2CALL
LUWID =< user connection>
PLAN NAME = CHCDTCT2
There is a timing window in the Faster Local socket processing
where a select or poll for write may hang and not get posted
even though the connection is in a writable state.
A selectex() socket call might no longer be used to provide
available buffer status when replicating millions of DB2 table
rows from a z/OS DB2 system to the same z/OS DB2 system. A
system trace can show that the task issuing the selectex() was
not being dispatched for quite some time. If an external action
(e.g. request task status) was performed, the ECB being passed
on the selectex() will get POSTed but after the task sends more
DB2 table rows, it becomes dormant again. A NETSTAT command
shows that the SndNxt and ClientSndNxt values are identical.
This situration affects the behavior of a long running UOR being applied by Change Data Capture on Z for a subscription.
The fix for TCPIP Hiper apar PM30744 (UK64673) needs to be applied
Hiper Apar PM30744, PTF UK64673 need to be applied to address this situation.