Db2 Connect Client steering thread recycle

Enhance Db2 Connect client for distributed workload.

problem statement:
Today Db2 DDF will close the connection to recycle the thread. This happens conditional (recycle-time limit, after Commit, no open cursors, other conditions). The client will find the socket being closed and will open a new connection, then continue workload on this new connection. Conditional SQL statements can be seamless replayed. This function is also used for accidential breaking connections.

Finding the connection lost could be in a state where SQL statements can't be replayed. This can happen in a window of network latency. Then the client needs to report SQLCODE -30108 against application. For accidental lost connections this works as designed, for periodical thread recycle there is a desire to prevent this occurence.

the idea:
instead breaking the connection from DDF-side let the client disconnect within the identical conditional model. This way the entire control of the connect handling is at the client side, no timing window would bring in uncertainty.

DRDA signaling could be used to identify the current setting, the thread recycle mechanism to be active at DDF or at client side.

If information about the thread state can only be obtained at the DDF side, DRDA signaling could be used to transport a 'go' immediate with synchronous Commit acknowledge to the client.

affected parts:
Db2 CLI , JDBC

additional details:

From https://www.ibm.com/docs/en/db2/11.5?topic=njcshacdzs-operation-automatic-client-reroute-connections-db2-zos-server-from-application-other-than-java-application

The following things listed and perhaps more are to be considered for “transparent” reconnect:

• SET special registers

• session global variables

• Open cursors with cursor-hold behavior

• Open cursors with locators

• Declared global temporary tables

• Accelerated queries