Control DDM conversations

The term connection in this topic collection refers to the concept of an SQL connection. An SQL connection lasts from the time an explicit or implicit SQL CONNECT is done until the logical SQL connection is terminated by such means as an SQL DISCONNECT, or a RELEASE followed by a COMMIT.

Multiple SQL connections can occur serially over a single network connection or conversation. In other words, when a connection is ended, the conversation that carried it is not necessarily ended.

Note: The term conversation has a specific, technical meaning in SNA APPC terminology. It does not extend to TCP/IP terminology in a formal sense. However, there is a similar concept in TCP/IP (a 'network connection' in other topics on the subject). In this topic collection, the word is used with the understanding that it applies to TCP/IP network connections as well. In other topics of this topic collection, the term retains its specific APPC meaning, but it is expected that the reader can discern that meaning from the context.

When an application requester (AR) uses DRDA® to connect to an application server (AS), it uses a DDM conversation. The conversation is established with the SQL CONNECT statement from the AR, but only if:

DDM conversations can be in one of three states: active, unused, or dropped. A DDM conversation used by the distributed relational database is active while the AR is connected to the AS.

The SQL DISCONNECT and RELEASE statements are used to end connections. Connections can also be ended implicitly by the server. In addition, when running with RUW connection management, previous connections are ended when a CONNECT is performed.

After a connection ends, the DDM conversations then either become unused or are dropped. If a DDM conversation is unused, the conversation to the remote database management system is maintained by the DDM communications manager and marked as unused. If a DDM conversation is dropped, the DDM communications manager ends the conversation. The DDMCNV job attribute determines whether DDM conversations for connections that are no longer active become unused or dropped. If the job attribute value is *KEEP and the connection is to another iSeries™ server, the conversation becomes unused. If the job attribute value is *DROP or the connection is not to another iSeries server, the conversation is dropped.

Using a DDMCNV job attribute of *KEEP is desirable when connections to remote relational databases are frequently changed.

A value of *DROP is desirable in the following situations:

If a DDM conversation is also being used to operate on remote files through DDM, the conversation will remain active until the following conditions are met:

Regardless of the value of the DDMCNV job attribute, conversations are dropped at the end of a job routing step, at the end of the job, or when the job initiates a Reroute Job (RRTJOB) command. Unused conversations within an active job can also be dropped by the Reclaim DDM Conversations (RCLDDMCNV) or Reclaim Resources (RCLRSC) command. Errors, such as communications line failures, can also cause conversations to drop.

The DDMCNV parameter is changed by the Change Job (CHGJOB) command and is displayed by Display Job (DSPJOB) command with OPTION(*DFNA). Also, you can use the Retrieve Job Attributes (RTVJOBA) command to get the value of this parameter and use it within a CL program.

Related reference
Change Job (CHGJOB) command
Display Job (DSPJOB) command
Explicit connection management
Reclaim DDM resources
Reclaim Resources (RCLRSC) command
Reroute Job (RRTJOB) command
Retrieve Job Attributes (RTVJOBA) command