SQL connections are managed at the activation group level. Each activation group within a job manages its own connections and these connections are not shared across activation groups.
Before the use of TCP/IP by DRDA®, the term connection was not ambiguous. It referred to a connection from the SQL point of view. That is, a connection started at the time one did a CONNECT TO some RDB, and ended when a DISCONNECT was done or a RELEASE ALL followed by a successful COMMIT occurred. The APPC conversation may or may not have been kept up, depending on the job's DDMCNV attribute value, and whether the conversation was with an iSeries™ or other type of system.
TCP/IP terminology does not include the term conversation. A similar concept exists, however. With the advent of TCP/IP support by DRDA, use of the term conversation is replaced, in this topic, by the more general term connection, unless the discussion is specifically about an APPC conversation. Therefore, there are now two different types of connections about which the reader must be aware: SQL connections of the type described above, and network connections which replace the term conversation.
Where there might be the possibility of confusion between the two types of connections, the word will be qualified by SQL or network to help the reader to understand the intended meaning.
The following is an example of an application that runs in multiple activation groups. This example is used to illustrate the interaction between activation groups, connection management, and commitment control. It is not a recommended coding style.