Controlling 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.

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:

• A conversation using the same remote location values does not already exist for the AR job.

• A conversation uses the same activation group.

• If started from DDM, a conversation has the file scoped to the activation group.

• A conversation has the same conversation type (protected or unprotected).

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 system. In addition, when running with RUW connection management, previous connections are ended when a CONNECT operation 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 are dropped. If the job attribute value is *KEEP and the connection is to another system, the conversation becomes unused. If the job attribute value is *DROP or the connection is not to another system, 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:

• When the cost of maintaining the conversation is high and the conversation will not be used relatively soon.

• When running with a mixture of programs compiled with RUW connection management and programs compiled with DUW connection management. Attempts to run programs compiled with RUW connection management to remote locations will fail when protected conversations exist.

• When running with protected conversations either with DDM or DRDA. Additional overhead is incurred on commits and rollbacks for unused protected conversations.

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:

• All the files used in the conversation are closed and unlocked

• No other DDM-related functions are being performed

• No DDM-related function has been interrupted (by a break program, for example)

• For protected conversations, a commit or rollback was performed after ending all SQL programs and after all DDM-related functions were completed

• An AR job is no longer connected to the AS

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.

• Reclaiming DDM resources
  The Reclaim Distributed Data Management Conversations (RCLDDMCNV) command reclaims all application conversations that are not currently being used by a source job, even if the DDMCNV attribute value for the job is *KEEP.

 

Parent topic:

Administration

 

Related reference

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