Communications variables

• Operating system: All, server only
• Default=100, Values: A numeric value that is greater than or equal to zero.
• This variable specifies the frequency of TCP/IP client connection verifications during an active transaction. It permits early detection of client termination, instead of waiting until after the completion of the query. If this variable is set to 0, no verification is performed.

  Lower values cause more frequent checks. As a guide, for low frequency, use 100; for medium frequency, use 50; for high frequency use 10. The value is measured in an internal DB2® metric. The values represent a linear scale, that is, increasing the value from 50 to 100 doubles the interval. Checking more frequently for client status while executing a database request lengthens the time taken to complete queries. If the DB2 workload is heavy (that is, it involves many internal requests), setting DB2CHECKCLIENTINTERVAL to a low value has a greater impact on performance than in a situation where the workload is light.

• Operating system: All, server only
• Default=NULL, Values: NPIPE, TCPIP, SSL
• This variable specifies the communication managers that are started when the database manager is started. If this variable is not set, no DB2 communications managers are started at the server. You can set this variable to any combination of the values, separated by commas.
  Note: The value NPIPE is valid only in Windows operating systems.

• Operating system: All supported DB2 Enterprise Server Edition platforms
• Default=TCPIP4, Values: TCPIP4 or TCPIP6
• This variable specifies how the host names in the db2nodes.cfg file are resolved. All host names are resolved as IPv4 or IPv6. If an IP address instead of a host name is specified in db2nodes.cfg, the form of the IP determines if IPv4 or IPv6 is used. If DB2FCMCOMM is not set, its default setting of IPv4 means that only IPv4 hosts can be started.
  Note: If the IP format resolved from the hostname specified in db2nodes.cfg, or the IP format directly specified in db2nodes.cfg does not match the setting of DB2FCMCOMM, db2start will fail.

• Operating system: AIX®, HP_UX, Solaris
• Default=FALSE, Values: TRUE or FALSE
• This variable is used to eliminate the chance of lock contention in multi-threaded applications. When this registry variable is TRUE, the code page and territory code information is saved the first time a thread accesses it. From that point, the cached information is used for any other thread that requests this information. This eliminates lock contention and results in a performance benefit in certain situations. This setting should not be used if the application changes locale settings between connections. It is probably not needed in such a situation because multi-threaded applications typically do not change their locale settings because it is not thread safe to do so.

• Operating system: All
• This registry variable controls a set of parameters that allow you to modify the behavior of various aspects of the DB2 internal infrastructure. Separate parameters with a semicolon, as in the following example:

  db2set
  DB2_PMODEL_SETTINGS=MLN_REMOTE_LISTENER:TRUE;ENHANCED_ROLLBACK:TRUE

• Parameters:

  MLN_REMOTE_LISTENER

  • Default: FALSE
  • Values: TRUE, FALSE
  • In Version 9.7 Fix Pack 3 and later, you can use the MLN_REMOTE_LISTENER parameter to start a TCP/IP listener on each logical database partition. If you set this option to TRUE, applications can connect directly to each logical database partition instead of routing requests through the database partition server that is assigned to logical port 0.

    If you set this option to TRUE, ensure that the additional TCP/IP listeners do not use ports that are required by other services.

  ENHANCED_ROLLBACK

  • Default: FALSE
  • Values: TRUE, FALSE
  • In Version 9.7 Fix Pack 3 and later, you can use the ENHANCED_ROLLBACK parameter to improve rollback behavior for units of work on a DB2 server that uses the partitioned database environment. If you set this option to TRUE, rollback requests for units of work are sent only to logical database partitions that participated in the transaction.

• Operating system: UNIX, Linux
• Default=rsh (remsh on HP-UX), Values are a full path name to rsh, remsh, or ssh
• By default, DB2 database system uses rsh as the communication protocol when starting remote database partitions and with the db2_all script to run utilities and commands on all database partitions. For example, setting this registry variable to the full path name for ssh causes DB2 database products to use ssh as the communication protocol for the requested running of the utilities and commands. It may also be set to the full path name of a script that invokes the remote command program with appropriate default parameters. This variable is only required for partitioned databases, or for single-partition environments where the db2start command is run from a different server than where the DB2 product was installed and for rsh or ssh dependant utilities that have the capability of starting, stopping or monitoring a DB2 instance, such as db2gcf. The instance owner must be able to use the specified remote shell program to log in from each DB2 database node to each other DB2 database node, without being prompted for any additional verification or authentication (that is, passwords or password phrases).

For detailed instructions on setting the DB2RSHCMD registry variable to use a ssh shell with DB2, see the white paper "Configure DB2 Universal Database™ for UNIX to use OpenSSH."

• Operating system: UNIX, Linux
• Default=30 seconds, Values: 1 - 120
• This variable is only applicable if DB2RSHCMD is set to a non-null value. This registry variable is used to control the timeout period that the DB2 database system will wait for any remote command. After this timeout period, if no response is received, the assumption is made that the remote database partition is not reachable and the operation has failed.
  Note: The time value given is not the time required to run the remote command, it is the time needed to authenticate the request.

• Operating system: All
• Default=65 536
• Specifies the value of TCP/IP receive buffers.

• Operating system: All
• Default=65 536
• Specifies the value of TCP/IP send buffers.

• Operating system: All, client only
• Default=0 (no timeout), Values: 0 - 32 767 seconds
• The DB2TCP_CLIENT_CONTIMEOUT registry variable specifies the number of seconds that a client must wait for the completion on a TCP/IP connect operation. A database connect operation via TCP/IP involves both connect() and recv() socket subroutines. The database manager returns the -30081 selectForConnectTimeout error if the connect() subroutine reaches the timeout, and the -30081 selectForRecvTimeout error if the recv() subroutine reaches the timeout.

  There is no timeout if the registry variable is not set or is set to 0.

  Note: Operating systems also have a connection timeout value that may take effect prior to the timeout you set using DB2TCP_CLIENT_CONTIMEOUT. For example, AIX has a default tcp_keepinit=150 (in half seconds) that would terminate the connection after 75 seconds.

• Operating system: AIX, Linux, Windows (client only)
• Default=15 Values: 0 - 32 767 seconds

• The DB2TCP_CLIENT_KEEPALIVE_TIMEOUT registry variable specifies the maximum time in seconds before an unresponsive TCP/IP client connection or attachment is detected as no longer alive. When this variable is not set, the default setting of 15 seconds is used. When the KeepAliveTimeout keyword is set to 0, the keepalive setting that is set in the operating system takes effect. If set, this variable takes precedence over any keepAliveTimeout setting as specified in the db2dsdriver.cfg file.

  Changes to this variable take effect immediately for all future TCP/IP connections and attachments to the server

• Operating system: All, client only
• Default=0 (no timeout), Values: 0 - 32 767 seconds
• The DB2TCP_CLIENT_RCVTIMEOUT registry variable specifies the number of seconds a client waits for data on a TCP/IP receive operation. If data from the server is not received in the seconds specified, then the DB2 database manager returns the error -30081 selectForRecvTimeout.

  There is no timeout if the registry variable is not set or is set to 0.

  Note: The value of the DB2TCP_CLIENT_RCVTIMEOUT can be overridden by the CLI, using the db2cli.ini keyword ReceiveTimeout or the connection attribute SQL_ATTR_RECEIVE_TIMEOUT.

• Operating system: All
• Default=1 on serial machines; square root of the number of processors rounded up to a maximum of sixteen connection managers on symmetric multiprocessor machines. Values: 1 to 16
• The default number of connection managers is created if the registry variable is not set. If the registry variable is set, the value assigned here overrides the default value. The number of TCP/IP connection managers specified up to a maximum of 16 is created. If less than 1 is specified then DB2TCPCONNMGRS is set to a value of 1 and a warning is logged that the value is out of range. If greater than 16 is specified then DB2TCPCONNMGRS is set to a value of 16 and a warning is logged that the value is out of range. Values between 1 and 16 are used as given. When there is greater than one connection manager created, connection throughput should improve when multiple client connections are received simultaneously. There may be additional TCP/IP connection manager processes (on UNIX) or threads (on Windows operating systems) if the user is running on a SMP machine, or has modified the DB2TCPCONNMGRS registry variable. Additional processes or threads require additional storage.
  Note: Having the number of connection managers set to 1 causes a drop in performance on remote connections in systems with a lot of users, frequent connects and disconnects, or both.