Communications variables

• Operating system: All
• Default=NO, Values: NO, YES
• This registry variable controls whether applications that access sequences are allowed to participate in workload balancing.

  When DB2_ALLOW_WLB_WITH_SEQUENCES is set to NO, applications that reference PREVIOUS VALUE or NEXT VALUE in an SQL sequence statement are prevented from participating in workload balancing.

  When DB2_ALLOW_WLB_WITH_SEQUENCES is set to YES, applications that reference PREVIOUS VALUE or NEXT VALUE in an SQL sequence statement are not prevented from participating in workload balancing. Applications must generate the next sequence value with the NEXT VALUE FOR sequence expression in a transaction before it references the previous value of the sequence using the PREVIOUS VALUE FOR sequence expression. Because the application can participate in workload balancing, each transaction might run in a new session or a different session. Accessing a previous sequence value in a transaction without first generating the next sequence value results in a SQL0845N error.

  Sequence considerations in a Db2 pureScale® environment:

  In a Db2 pureScale environment, if you use the CACHE and NO ORDER options, multiple caches might be active simultaneously. Requests for the next value from different members might not result in the assignment of values in strict numeric order. For example, members DB2A and DB2B are using the same sequence. DB2A gets the cache values 1-20, while DB2B gets the cache values 21-40. If DB2A requested the next value first, then DB2B requested, and then DB2A requested again, the order of values assigned would be 1, 21, 2.

  Using the ORDER or NO CACHE option ensures that the values assigned to a sequence shared by one or more applications across multiple members are in strict numeric order. If ORDER is specified, then NO CACHE is implied even if CACHE n is specified.

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

  Note: If this variable is set to 0, this may lead to orphaned connections that may lead to transactions holding back the active log. This will result in applications failing with a log full (SQL0964N) error.

• Operating system: All
• Default: OFF
• Starting in Db2 11.1 MP4 FP5, this parameter is used to control whether the value of the SSL_SVR_LABEL DBM configuration parameter is configurable online. For more information, see SSL_SVR_LABEL.
• Changes to this variable do not take effect immediately by default. To have them take effect immediately, issue the db2set command with the -immediate parameter.

• 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
• Changes to this variable will take effect immediately for all future compiled SQL statements. There is no need to restart the instance or to issue the db2set command with the -immediate parameter.
• 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;SRVLST_EQUAL_WEIGHT:TRUE

• Parameters:

  ENHANCED_ROLLBACK

  • Default: FALSE
  • Values: TRUE, FALSE
  • Use the ENHANCED_ROLLBACK parameter to improve rollback behavior for units of work on Db2 servers in partitioned database environments. 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.

  MLN_REMOTE_LISTENER

  • Default: FALSE
  • Values: TRUE, FALSE
  • 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.

  SRVLST_EQUAL_WEIGHT

  • Default: FALSE
  • Values: TRUE, FALSE
  • Use the SRVLST_EQUAL_WEIGHT parameter if you want non-zero member weights in the server list to always be identical, thereby overriding the default behavior in which member weights are computed based on load. Member weights as contained in the server list are used by a remote client to distribute workload when workload balancing (WLB) is enabled.

    If you set this option to TRUE, WLB at the client translates into even workload distribution among members with no regard for the member load.

• 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.
• Changes to this variable will take effect immediately for all future compiled SQL statements. There is no need to restart the instance or to issue the db2set command with the -immediate parameter.

• Operating system: AIX, HP-UX, Linux, Windows (client only)
• Default=15, Values: 0 - 32 767 seconds
• The DB2TCP_CLIENT_KEEPALIVE_TIMEOUT registry variable represents the total amount of time in seconds a socket can remain idle; and not respond to keepalive probes before it is considered unresponsive. When a socket is considered unresponsive, it is terminated by Db2. It is the client-side equivalent of DB2TCP_SERVER_KEEPALIVE_TIMEOUT.

  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.
• Changes to this variable will take effect immediately for all future compiled SQL statements. There is no need to restart the instance or to issue the db2set command with the -immediate parameter.

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

• Operating system: AIX, HP-UX, Linux, Windows (server only)
• Default=60, Values: 0 - 32 767 seconds

• The DB2TCP_SERVER_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. It is the server-side equivalent of DB2TCP_CLIENT_KEEPALIVE_TIMEOUT and keepAliveTimeout. When this variable is not set, the default setting of 60 seconds is used.

  Changes to this variable take effect immediately for all future TCP/IP connections and attachments to the server. There is no need to restart the server instance.