TCP/IP Communication Error

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • sraghav
    New Member
    • Jul 2007
    • 1

    TCP/IP Communication Error

    Hi,

    I have a remote server.. From client machine did catalog tcip and catalog database on the remote databse. I am unable to do a test connection from client.

    Getting the following error, tried all options but couldn't get it working. Greatly appreciate your assistance

    SQL30081N A communication error has been detected. Communication protocol
    being used: "TCP/IP". Communication API being used: "SOCKETS". Location
    where the error was detected: "DB2 server IP". Communication function
    detecting the error: "connect". Protocol specific error code(s): "10060", "*",
    "*". SQLSTATE=08001

    Regards,
    Srini
  • Shashank1984
    New Member
    • Jul 2007
    • 26

    #2
    The specific return code listed in this
    error output is a 10061, which is the tcp/ip error ECONNREFUSED. "The
    connection has been refused. If you are trying to connect to the
    database, check that the database manager and TCP/IP protocol support at
    the server has been started successfully".
    Typically this particular error message occurs under one of the
    following scenarios:
    1. The instance is not running. Issue a db2start to confirm that the
    instance is online and try the connection again.
    2. The instance on the remote server has not been configured to accept
    TCP/IP communication requests. On the server, please verify the
    following:
    a. Issue a db2set -all and confirm that the parameter DB2COMM=TCPIP.
    If this is not set, issue:
    db2set DB2COMM=TCPIP
    b. Issue the command "db2 get dbm cfg | grep SVCENAME" and confirm that
    this parameter is not blank. This may either specify a service name
    defined in your /etc/services file, or a port number, but this value
    must be set. If this is blank, please update the dbm cfg using:
    db2 update dbm cfg using SVCENAME 50000
    db2stop
    db2start
    Once the instance has been restarted, verify that the TCP/IP port is
    listening with the command:
    netstat -an | grep 50000
    This should return output similar to the following:
    tcp4 0 0 *.50000 *.*
    LISTEN
    Also note that if the SVCENAME parameter specifies a service name rather
    than a port number, this service name must be defined in /etc/services.
    3. The catalog on the client has specified the wrong port number. On
    the client, please issue the command "db2 list node directory" and
    locate the entry for the system in question. Please verify that the
    port number listed here under the Service name field matches that of the
    port number specified in the SVCENAME parameter on the server. As on
    the server, if the service name specifies a name rather than a port,
    this must exist by the same name (case sensitive) in the /etc/services
    file on Unix, or in the C:\Windows\Syst em32\drivers\et c\services file on
    Windows.
    4. The catalog on the client may have the wrong host name specified, or
    a correct host name that can not be identified by the network. Please
    check the Hostname parameter in the "db2 list node directory" from item
    3 above, and confirm if this target can be reached using the ping
    command:
    ping <hostname>
    If the ping is successful, your network should be configured correctly
    to reach this machine. If the ping failed, please verify that the
    /etc/hosts file on the client (if Unix) or the
    C:\Windows\syst em32\drivers\et c\hosts file (on Windows) has an IP
    address specified for this host name. Alternately, you may catalog the
    connection directly specifying the IP address.
    5. If the client and the server are on opposite sides of a firewall,
    please ensure that your firewall or router are not configured to block
    communication on the port specified for the SVCENAME parameter on the
    server.

    Thank you,
    Shashank K.

    Comment

    Working...