Topic
  • 20 replies
  • Latest Post - ‏2012-04-26T12:31:46Z by kanchana0327
kanchana0327
kanchana0327
16 Posts

Pinned topic Unable to connect database remotely

‏2012-04-23T09:39:10Z |
Dear All
I have installed *DB2 9.7 on ZVM(susee linux on ZOS*) and having one instance (db2inst1) & created database - TPM_SCM in the server. I have cataloged the TPM_SCM database from the client machines(Windows & linux). I am getting communication socket error as mentioned below.

Error(Windows)

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

Client as well as the server are in same lan, Firewall is not there and necessary updates done in the cfg file(db2c_db2inst1).
I have checked in the ibm sites for this error code (10060), that to update the keepalive parameter. I dont know how to update the same.
And more over i am able remotely connect other databases from this problematic server.

Kindly guide me to fix the issue and please tell me if you require any other information.
  • mor
    mor
    577 Posts

    Re: Unable to connect database remotely

    ‏2012-04-23T10:13:30Z  
    The most likely answer is that you did not configure
    the Windows-client correctly.

    What is the port-number that the db2inst1 listens on?

    On the z/linux, is DB2COMM=TCPIP set ?

    On your Windows machine do you have installed the
    exact same DB2-client version and fixpack as the
    DB2-server on Linux (z/linux)?

    From your Windows machine can you "ping" successfully
    the z/linux hostname and/or tcp/ip-address ?

    On your Windows machine, run db2cwadmin.exe (Win7)
    or db2cmd.exe in administrator mode and
    give an attachment showing the output of
    these commands:

    db2 list node directory

    db2 list db directory
  • kanchana0327
    kanchana0327
    16 Posts

    Re: Unable to connect database remotely

    ‏2012-04-23T11:23:52Z  
    • mor
    • ‏2012-04-23T10:13:30Z
    The most likely answer is that you did not configure
    the Windows-client correctly.

    What is the port-number that the db2inst1 listens on?

    On the z/linux, is DB2COMM=TCPIP set ?

    On your Windows machine do you have installed the
    exact same DB2-client version and fixpack as the
    DB2-server on Linux (z/linux)?

    From your Windows machine can you "ping" successfully
    the z/linux hostname and/or tcp/ip-address ?

    On your Windows machine, run db2cwadmin.exe (Win7)
    or db2cmd.exe in administrator mode and
    give an attachment showing the output of
    these commands:

    db2 list node directory

    db2 list db directory
    Actually i have performed the re-cataloged also. At the same time i am able to others servers from the windows machine and also i couldn't connect the TPM_SCM(problematic server) from any of the unix boxes which are same lan.

    Please find the answers for your questions.
    What is the port-number that the db2inst1 listens on? -- (*50001)*

    pts/016:47:03:db2inst1@linux-ojyd ~>netstat -an | grep LISTEN |grep 50001
    tcp 0 0 0.0.0.0:50001 0.0.0.0: LISTEN*

    On the z/linux, is DB2COMM=TCPIP set ?

    pts/016:46:51:db2inst1@linux-ojyd ~>db2 get dbm cfg | grep SVC
    TCP/IP Service name (SVCENAME) = db2c_db2inst1
    SSL service name (SSL_SVCENAME) =
    pts/016:46:59:db2inst1@linux-ojyd ~>cat /etc/services | grep db2c_db2inst1
    db2c_db2inst1 50001/tcp

    On your Windows machine do you have installed the
    exact same DB2-client version and fixpack as the
    DB2-server on Linux (z/linux)?

    Server Db2 version - 9.7
    Client Windows Db2 version - 9.5
    Client Linux db2 version - 9.1 Fixpack 3

    From your Windows machine can you "ping" successfully
    the z/linux hostname and/or tcp/ip-address ?

    From the client machine(windows & linux) able to ping and able to connect via putty(ssh) to the server
    But unable to telnet with the port no- 50001, Though both are in same lan.

    On your Windows machine, run db2cwadmin.exe (Win7)
    or db2cmd.exe in administrator mode and
    give an attachment showing the output of
    these commands:

    Please find the attachments
    db2 list node directory

    db2 list db directory
  • mor
    mor
    577 Posts

    Re: Unable to connect database remotely

    ‏2012-04-23T14:02:47Z  
    Actually i have performed the re-cataloged also. At the same time i am able to others servers from the windows machine and also i couldn't connect the TPM_SCM(problematic server) from any of the unix boxes which are same lan.

    Please find the answers for your questions.
    What is the port-number that the db2inst1 listens on? -- (*50001)*

    pts/016:47:03:db2inst1@linux-ojyd ~>netstat -an | grep LISTEN |grep 50001
    tcp 0 0 0.0.0.0:50001 0.0.0.0: LISTEN*

    On the z/linux, is DB2COMM=TCPIP set ?

    pts/016:46:51:db2inst1@linux-ojyd ~>db2 get dbm cfg | grep SVC
    TCP/IP Service name (SVCENAME) = db2c_db2inst1
    SSL service name (SSL_SVCENAME) =
    pts/016:46:59:db2inst1@linux-ojyd ~>cat /etc/services | grep db2c_db2inst1
    db2c_db2inst1 50001/tcp

    On your Windows machine do you have installed the
    exact same DB2-client version and fixpack as the
    DB2-server on Linux (z/linux)?

    Server Db2 version - 9.7
    Client Windows Db2 version - 9.5
    Client Linux db2 version - 9.1 Fixpack 3

    From your Windows machine can you "ping" successfully
    the z/linux hostname and/or tcp/ip-address ?

    From the client machine(windows & linux) able to ping and able to connect via putty(ssh) to the server
    But unable to telnet with the port no- 50001, Though both are in same lan.

    On your Windows machine, run db2cwadmin.exe (Win7)
    or db2cmd.exe in administrator mode and
    give an attachment showing the output of
    these commands:

    Please find the attachments
    db2 list node directory

    db2 list db directory
    The catalog information looks OK, as long as you terminated after catalog action.
    Some more suggestions...
    On z/linux, running as db2inst1
    what is the output of

    db2set -all

    On z/linux, what is the output of:
    db2 get dbm cfg | grep -i authentication

    You wrote that there is no firewall between your windows workstation and z/linux.
    ssh works so port 22 is opened (or whatever port you use for ssh).
    Prove port 50001 is opened all the way.
    example : telnet 172.16.111.178 50001
    (if telnetd is running on z/linux it should give an error but not related to communication).
    or
    from z/linux can you ping your workstation? (should work in either direction).
    or
    from z/linux, can you see in db2diag.log (with DIAGLEVEL=4) the attempted connection from your workstation?
    or
    from z/linux, your sysadmin can use iptrace to see if there's any packets coming from your workstation on port 50001
    At your windows workstation is this your sequence of steps (in a db2cmd.exe window):
    db2 terminate
    db2 connect to ASSET user XXX using YYYY
    (where XXX is the account name you are trying to connect with, and YYYY is its password).
    --> then you get the failure?
  • kanchana0327
    kanchana0327
    16 Posts

    Re: Unable to connect database remotely

    ‏2012-04-24T05:20:03Z  
    • mor
    • ‏2012-04-23T14:02:47Z
    The catalog information looks OK, as long as you terminated after catalog action.
    Some more suggestions...
    On z/linux, running as db2inst1
    what is the output of

    db2set -all

    On z/linux, what is the output of:
    db2 get dbm cfg | grep -i authentication

    You wrote that there is no firewall between your windows workstation and z/linux.
    ssh works so port 22 is opened (or whatever port you use for ssh).
    Prove port 50001 is opened all the way.
    example : telnet 172.16.111.178 50001
    (if telnetd is running on z/linux it should give an error but not related to communication).
    or
    from z/linux can you ping your workstation? (should work in either direction).
    or
    from z/linux, can you see in db2diag.log (with DIAGLEVEL=4) the attempted connection from your workstation?
    or
    from z/linux, your sysadmin can use iptrace to see if there's any packets coming from your workstation on port 50001
    At your windows workstation is this your sequence of steps (in a db2cmd.exe window):
    db2 terminate
    db2 connect to ASSET user XXX using YYYY
    (where XXX is the account name you are trying to connect with, and YYYY is its password).
    --> then you get the failure?
    The catalog information looks OK, as long as you terminated after catalog action.
    Some more suggestions...

    On z/linux, running as db2inst1
    what is the output of

    db2set -all
    -----------------
    pts/010:03:56:db2inst1@linux-ojyd ~>db2set -all
    [i] DB2TCP_CLIENT_KEEPALIVE_TIMEOUT=1000
    [i] DB2COMM=tcpip
    [g] DB2SYSTEM=linux-ojyd
    [g] DB2INSTDEF=db2inst1
    [g] DB2ADMINSERVER=dasusr2

    On z/linux, what is the output of:
    db2 get dbm cfg | grep -i authentication

    pts/010:04:16:db2inst1@linux-ojyd ~>db2 get dbm cfg | grep -i authentication
    Server Connection Authentication (SRVCON_AUTH) = NOT_SPECIFIED
    Database manager authentication (AUTHENTICATION) = SERVER
    Alternate authentication (ALTERNATE_AUTH_ENC) = NOT_SPECIFIED
    Trusted client authentication (TRUST_CLNTAUTH) = CLIENT
    Bypass federated authentication (FED_NOAUTH) = NO

    You wrote that there is no firewall between your windows workstation and z/linux.
    ssh works so port 22 is opened (or whatever port you use for ssh).
    Prove port 50001 is opened all the way.
    example : telnet 172.16.111.178 50001
    (if telnetd is running on z/linux it should give an error but not related to communication).

    You are right. I couldn't telnet from any client machines(windows & linux) with the port no-50001

    or
    from z/linux can you ping your workstation? (should work in either direction).

    Ya i am able to ping the server from both side.(client to server as well from server to client).

    or
    from z/linux, can you see in db2diag.log (with DIAGLEVEL=4) the attempted connection from your workstation?

    I m not getting any log entries after changing the DIAGLEVEL 4(initially it was 3) in the Z/linux server. But last month(14thmarch2012) i got the diaglog. I have attached the same here. Please refer.(command- db2diag -level "Error, Severe, Warning")

    from z/linux, your sysadmin can use iptrace to see if there's any packets coming from your workstation on port 50001

    From the windows machine, while connectiog, i am only get the "synsent" status and it is not established the connectivity.
    TCP 172.20.211.82:3818 172.16.111.178:50001 SYN_SENT

    At your windows workstation is this your sequence of steps (in a db2cmd.exe window):
    db2 terminate
    db2 connect to ASSET user XXX using YYYY
    (where XXX is the account name you are trying to connect with, and YYYY is its password).
    --> then you get the failure?

    I m not using db2 terminate. Please find the steps which i am connecting the TPM_SCM db from the windows client machine.
    C:\Documents and Settings\202892>db2 connect to ASSET user db2inst1
    Enter current password for db2inst1:
    SQL30081N A communication error has been detected. Communication protocol
    being used: "TCP/IP". Communication API being used: "SOCKETS". Location
    where the error was detected: "172.16.111.178". Communication function
    detecting the error: "connect". Protocol specific error code(s): "10060", "",*
    "". SQLSTATE=08001*
  • mor
    mor
    577 Posts

    Re: Unable to connect database remotely

    ‏2012-04-24T05:58:16Z  
    The catalog information looks OK, as long as you terminated after catalog action.
    Some more suggestions...

    On z/linux, running as db2inst1
    what is the output of

    db2set -all
    -----------------
    pts/010:03:56:db2inst1@linux-ojyd ~>db2set -all
    [i] DB2TCP_CLIENT_KEEPALIVE_TIMEOUT=1000
    [i] DB2COMM=tcpip
    [g] DB2SYSTEM=linux-ojyd
    [g] DB2INSTDEF=db2inst1
    [g] DB2ADMINSERVER=dasusr2

    On z/linux, what is the output of:
    db2 get dbm cfg | grep -i authentication

    pts/010:04:16:db2inst1@linux-ojyd ~>db2 get dbm cfg | grep -i authentication
    Server Connection Authentication (SRVCON_AUTH) = NOT_SPECIFIED
    Database manager authentication (AUTHENTICATION) = SERVER
    Alternate authentication (ALTERNATE_AUTH_ENC) = NOT_SPECIFIED
    Trusted client authentication (TRUST_CLNTAUTH) = CLIENT
    Bypass federated authentication (FED_NOAUTH) = NO

    You wrote that there is no firewall between your windows workstation and z/linux.
    ssh works so port 22 is opened (or whatever port you use for ssh).
    Prove port 50001 is opened all the way.
    example : telnet 172.16.111.178 50001
    (if telnetd is running on z/linux it should give an error but not related to communication).

    You are right. I couldn't telnet from any client machines(windows & linux) with the port no-50001

    or
    from z/linux can you ping your workstation? (should work in either direction).

    Ya i am able to ping the server from both side.(client to server as well from server to client).

    or
    from z/linux, can you see in db2diag.log (with DIAGLEVEL=4) the attempted connection from your workstation?

    I m not getting any log entries after changing the DIAGLEVEL 4(initially it was 3) in the Z/linux server. But last month(14thmarch2012) i got the diaglog. I have attached the same here. Please refer.(command- db2diag -level "Error, Severe, Warning")

    from z/linux, your sysadmin can use iptrace to see if there's any packets coming from your workstation on port 50001

    From the windows machine, while connectiog, i am only get the "synsent" status and it is not established the connectivity.
    TCP 172.20.211.82:3818 172.16.111.178:50001 SYN_SENT

    At your windows workstation is this your sequence of steps (in a db2cmd.exe window):
    db2 terminate
    db2 connect to ASSET user XXX using YYYY
    (where XXX is the account name you are trying to connect with, and YYYY is its password).
    --> then you get the failure?

    I m not using db2 terminate. Please find the steps which i am connecting the TPM_SCM db from the windows client machine.
    C:\Documents and Settings\202892>db2 connect to ASSET user db2inst1
    Enter current password for db2inst1:
    SQL30081N A communication error has been detected. Communication protocol
    being used: "TCP/IP". Communication API being used: "SOCKETS". Location
    where the error was detected: "172.16.111.178". Communication function
    detecting the error: "connect". Protocol specific error code(s): "10060", "",*
    "". SQLSTATE=08001*
    You show two tcp/ip addresses:

    172.16.111.178 (your z/linux)

    172.20.211.82 ( workstation with db2-client ?? - please confirm )

    They seem to be on different networks or subnets (I don't know your netmask).
    From z/linux, what is the output of

    tracert your-workstation-ip-address

    From your workstation, what is the output of:

    tracert 172.16.111.178

    Ask your sysadmin to check the path between workstation and server, and verify that port 50001 is opened all the way.

    Your diaglog is not what I asked.
    I need only a small piece of db2diag.log, at DIAGLEVEL=4
    showing only for the few seconds before/during/after the db2-connect attempt ALL of the entries (including Info entries).

    So if it takes 60 seconds to try the connect, only
    show the db2diag.log contents for the surrounding time period.
    The only thing I'm looking for is any evidence of a
    connection attempt. However, if your iptrace was properly
    done and if it shows no traffic from your workstation
    destined for port 50001 on your server then it looks
    like something is blocking that port, and if that is true
    then there will be no relevant entries in db2diag.log.

    If your network/router configuration is beyond your
    control and you know that ssh works fine, then you
    can tunnel DB2 traffic via the ssh port.
    If you are unfamiliar with tunnelling then your
    sysadmin can show you how to use ssh (on your client)
    to do the tunnelling. It is straightforward with
    openssh on linux or cygwin, and possible (but a bit awkward) with putty.
    But for normal operation, it is more easy when the db2 port is opened of course.
  • kanchana0327
    kanchana0327
    16 Posts

    Re: Unable to connect database remotely

    ‏2012-04-24T07:37:52Z  
    • mor
    • ‏2012-04-24T05:58:16Z
    You show two tcp/ip addresses:

    172.16.111.178 (your z/linux)

    172.20.211.82 ( workstation with db2-client ?? - please confirm )

    They seem to be on different networks or subnets (I don't know your netmask).
    From z/linux, what is the output of

    tracert your-workstation-ip-address

    From your workstation, what is the output of:

    tracert 172.16.111.178

    Ask your sysadmin to check the path between workstation and server, and verify that port 50001 is opened all the way.

    Your diaglog is not what I asked.
    I need only a small piece of db2diag.log, at DIAGLEVEL=4
    showing only for the few seconds before/during/after the db2-connect attempt ALL of the entries (including Info entries).

    So if it takes 60 seconds to try the connect, only
    show the db2diag.log contents for the surrounding time period.
    The only thing I'm looking for is any evidence of a
    connection attempt. However, if your iptrace was properly
    done and if it shows no traffic from your workstation
    destined for port 50001 on your server then it looks
    like something is blocking that port, and if that is true
    then there will be no relevant entries in db2diag.log.

    If your network/router configuration is beyond your
    control and you know that ssh works fine, then you
    can tunnel DB2 traffic via the ssh port.
    If you are unfamiliar with tunnelling then your
    sysadmin can show you how to use ssh (on your client)
    to do the tunnelling. It is straightforward with
    openssh on linux or cygwin, and possible (but a bit awkward) with putty.
    But for normal operation, it is more easy when the db2 port is opened of course.
    You show two tcp/ip addresses:

    172.16.111.178 (your z/linux)

    172.20.211.82 ( workstation with db2-client ?? - please confirm )
    --------- S you are correct ----------------------------------------

    They seem to be on different networks or subnets (I don't know your netmask).

    From z/linux, what is the output of

    tracert your-workstation-ip-address
    ---------------------------------------------------
    pts/012:51:24:root@linux-ojyd ~>/usr/sbin/traceroute 172.20.211.82
    traceroute to 172.20.211.82 (172.20.211.82), 30 hops max, 40 byte packets using UDP
    Unable to look up 172.16.111.2: Temporary failure in name resolution
    1 172.16.111.2 0.327 ms 0.320 ms 0.300 ms
    Unable to look up 172.24.253.161: Temporary failure in name resolution
    2 172.24.253.161 0.287 ms 0.291 ms 0.286 ms
    Unable to look up 10.70.44.126: Temporary failure in name resolution
    3 10.70.44.126 4.200 ms 3.163 ms 3.481 ms
    Unable to look up 172.24.253.18: Temporary failure in name resolution
    4 172.24.253.18 4.436 ms 3.652 ms 3.318 ms
    Unable to look up 172.20.211.82: Temporary failure in name resolution
    5 172.20.211.82 3.272 ms 3.262 ms 4.355 ms
    From your workstation, what is the output of:

    tracert 172.16.111.178

    C:\Documents and Settings\202892>tracert 172.16.111.178

    Tracing route to linux-ojyd http://172.16.111.178
    over a maximum of 30 hops:

    1 42 ms <1 ms <1 ms 172.20.211.1
    2 1 ms <1 ms <1 ms 172.24.253.17
    3 3 ms 2 ms 3 ms 10.70.44.125
    4 3 ms 3 ms 3 ms 172.24.253.166
    5 3 ms 3 ms 3 ms linux-ojyd http://172.16.111.178

    Trace complete.

    Ask your sysadmin to check the path between workstation and server, and verify that port 50001 is opened all the way.

    I have checked with the sysadmin, that there is no firewall between, since both are in same lan

    Your diaglog is not what I asked.
    I need only a small piece of db2diag.log, at DIAGLEVEL=4
    showing only for the few seconds before/during/after the db2-connect attempt ALL of the entries (including Info entries).
    So if it takes 60 seconds to try the connect, only
    show the db2diag.log contents for the surrounding time period.
    The only thing I'm looking for is any evidence of a
    connection attempt. However, if your iptrace was properly
    done and if it shows no traffic from your workstation
    destined for port 50001 on your server then it looks
    like something is blocking that port, and if that is true
    then there will be no relevant entries in db2diag.log.

    If your network/router configuration is beyond your
    control and you know that ssh works fine, then you
    can tunnel DB2 traffic via the ssh port.
    If you are unfamiliar with tunnelling then your
    sysadmin can show you how to use ssh (on your client)
    to do the tunnelling. It is straightforward with
    openssh on linux or cygwin, and possible (but a bit awkward) with putty.
    But for normal operation, it is more easy when the db2 port is opened of course.


    I have changed the Diaglevel to 4 and execute the db2diag.log. i m not getting any logs.
    Please refer below.
    pts/113:09:14:db2inst1@linux-ojyd ~>db2diag -level "Error, Severe, Warning"
    pts/113:09:24:db2inst1@linux-ojyd ~>db2 get dbm cfg | grep DIAGLEVEL
    Diagnostic error capture level (DIAGLEVEL) = 3
    pts/113:10:12:db2inst1@linux-ojyd ~>db2 update dbm cfg using diaglevel 4
    DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completed
    successfully.
    pts/113:10:46:db2inst1@linux-ojyd ~>db2 get dbm cfg | grep DIAGLEVEL
    Diagnostic error capture level (DIAGLEVEL) = 4
    pts/113:10:49:db2inst1@linux-ojyd ~>db2diag -level "Error, Severe, Warning"
    pts/113:10:55:db2inst1@linux-ojyd ~>
  • mor
    mor
    577 Posts

    Re: Unable to connect database remotely

    ‏2012-04-24T10:45:11Z  
    • mor
    • ‏2012-04-24T05:58:16Z
    You show two tcp/ip addresses:

    172.16.111.178 (your z/linux)

    172.20.211.82 ( workstation with db2-client ?? - please confirm )

    They seem to be on different networks or subnets (I don't know your netmask).
    From z/linux, what is the output of

    tracert your-workstation-ip-address

    From your workstation, what is the output of:

    tracert 172.16.111.178

    Ask your sysadmin to check the path between workstation and server, and verify that port 50001 is opened all the way.

    Your diaglog is not what I asked.
    I need only a small piece of db2diag.log, at DIAGLEVEL=4
    showing only for the few seconds before/during/after the db2-connect attempt ALL of the entries (including Info entries).

    So if it takes 60 seconds to try the connect, only
    show the db2diag.log contents for the surrounding time period.
    The only thing I'm looking for is any evidence of a
    connection attempt. However, if your iptrace was properly
    done and if it shows no traffic from your workstation
    destined for port 50001 on your server then it looks
    like something is blocking that port, and if that is true
    then there will be no relevant entries in db2diag.log.

    If your network/router configuration is beyond your
    control and you know that ssh works fine, then you
    can tunnel DB2 traffic via the ssh port.
    If you are unfamiliar with tunnelling then your
    sysadmin can show you how to use ssh (on your client)
    to do the tunnelling. It is straightforward with
    openssh on linux or cygwin, and possible (but a bit awkward) with putty.
    But for normal operation, it is more easy when the db2 port is opened of course.
    The tracert output suggests:

    (1) The routes from workstation to z/linux
    are different from the return route.
    That seems unusual to me, as if the routes are misconfigured.
    Ask your network-admin to explain why the paths are different in either direction.
    How have you proved that port 50001 is opened on these
    intervening hops for the return path from z/linux to workstation:
    172.16.111.178 (your z/linux)
    172.16.111.2
    172.24.253.161
    10.70.44.126
    172.24.253.18
    172.20.211.82 (your workstation)
    (2) How have you proved that port 50001
    is opened on these hops on the outgoing path from workstation
    to z/linux:
    172.20.211.82 (your workstation)
    172.24.253.17
    10.70.44.125
    172.24.253.166
    172.16.111.178 (your z/linux)

    Just because source and target are in "the same LAN"
    does not mean there are no firewalls. You have to
    prove it.

    A firewall is not necessarily a bit of hardware.
    It can be a piece of software running on Windows or Linux.

    For example, on your Windows workstation(s) is the
    Windows-firewall activated on the LAN-connection ?
    (normally it will be running, for modern versions of Windows (Vista/Win7 etc).

    If it is running, have you created a rule on Windows firewall to allow port 50001 or both inbound and outbound traffic?

    Similarly on your linux workstation, is there a software-firewall
    activated - you might need to allow port 50001.
    I certainly had to do that on Red-Hat Linux 6.2 recently.

    Same on the z/linux, it may have a software-firewall
    implemented - it needs to allow traffic on the db2 port.
    Note: For db2diag you are still doing the wrong thing.
    Read my request in previous post more carefully, because
    the command you are runing cannot give what I asked.
    However, I'm still suspecting that port 50001 is blocked
    by one or more hops. So prove that first.
  • kanchana0327
    kanchana0327
    16 Posts

    Re: Unable to connect database remotely

    ‏2012-04-24T12:24:21Z  
    • mor
    • ‏2012-04-24T10:45:11Z
    The tracert output suggests:

    (1) The routes from workstation to z/linux
    are different from the return route.
    That seems unusual to me, as if the routes are misconfigured.
    Ask your network-admin to explain why the paths are different in either direction.
    How have you proved that port 50001 is opened on these
    intervening hops for the return path from z/linux to workstation:
    172.16.111.178 (your z/linux)
    172.16.111.2
    172.24.253.161
    10.70.44.126
    172.24.253.18
    172.20.211.82 (your workstation)
    (2) How have you proved that port 50001
    is opened on these hops on the outgoing path from workstation
    to z/linux:
    172.20.211.82 (your workstation)
    172.24.253.17
    10.70.44.125
    172.24.253.166
    172.16.111.178 (your z/linux)

    Just because source and target are in "the same LAN"
    does not mean there are no firewalls. You have to
    prove it.

    A firewall is not necessarily a bit of hardware.
    It can be a piece of software running on Windows or Linux.

    For example, on your Windows workstation(s) is the
    Windows-firewall activated on the LAN-connection ?
    (normally it will be running, for modern versions of Windows (Vista/Win7 etc).

    If it is running, have you created a rule on Windows firewall to allow port 50001 or both inbound and outbound traffic?

    Similarly on your linux workstation, is there a software-firewall
    activated - you might need to allow port 50001.
    I certainly had to do that on Red-Hat Linux 6.2 recently.

    Same on the z/linux, it may have a software-firewall
    implemented - it needs to allow traffic on the db2 port.
    Note: For db2diag you are still doing the wrong thing.
    Read my request in previous post more carefully, because
    the command you are runing cannot give what I asked.
    However, I'm still suspecting that port 50001 is blocked
    by one or more hops. So prove that first.
    Thanks for your suggestion Mor.

    I will clearly check about the Routing details.

    Could you please let me know how to check the db2diag.log Kindly share me the commands.
  • mor
    mor
    577 Posts

    Re: Unable to connect database remotely

    ‏2012-04-24T12:58:13Z  
    Thanks for your suggestion Mor.

    I will clearly check about the Routing details.

    Could you please let me know how to check the db2diag.log Kindly share me the commands.
    Don't forget to check the software-firewalls that I previously mentioned.

    Use any pager or editor of your choice to view the db2diag.log file.
    It is a plain text file on Linux.
    It can be very big so you only want a tiny piece of it.
    For example: less db2diag.log
    more db2diag.log
    view db2diag.log (this is the vi editor in read-only mode).
    The name and location of the db2diag.log can vary: study the Infocenter documentation to find how to locate it but by default it lives in $INSTHOME/sqllib/db2dump/db2diag.log where $INSTHOME = ~db2inst1 on your z/linux if db2inst1 is your instance name.
  • kanchana0327
    kanchana0327
    16 Posts

    Re: Unable to connect database remotely

    ‏2012-04-25T05:27:48Z  
    • mor
    • ‏2012-04-24T12:58:13Z
    Don't forget to check the software-firewalls that I previously mentioned.

    Use any pager or editor of your choice to view the db2diag.log file.
    It is a plain text file on Linux.
    It can be very big so you only want a tiny piece of it.
    For example: less db2diag.log
    more db2diag.log
    view db2diag.log (this is the vi editor in read-only mode).
    The name and location of the db2diag.log can vary: study the Infocenter documentation to find how to locate it but by default it lives in $INSTHOME/sqllib/db2dump/db2diag.log where $INSTHOME = ~db2inst1 on your z/linux if db2inst1 is your instance name.
    Kindly find the diaglog
  • mor
    mor
    577 Posts

    Re: Unable to connect database remotely

    ‏2012-04-25T07:48:32Z  
    Kindly find the diaglog
    You attached a file more than 400kb from 12/March to 25/April, and you gave no indication of the timestamp(s) when the connection attempts started and stopped. Maybe you lack the skills to follow the instructions.
    Never mind, the most likely cause is that port 50001 is blocked.
    Just persist with identifying the place(s) where that port is not opened, paying particular attention to the endpoints.
  • mor
    mor
    577 Posts

    Re: Unable to connect database remotely

    ‏2012-04-25T07:53:24Z  
    • mor
    • ‏2012-04-25T07:48:32Z
    You attached a file more than 400kb from 12/March to 25/April, and you gave no indication of the timestamp(s) when the connection attempts started and stopped. Maybe you lack the skills to follow the instructions.
    Never mind, the most likely cause is that port 50001 is blocked.
    Just persist with identifying the place(s) where that port is not opened, paying particular attention to the endpoints.
    One other thing is that your wrote that your z/linux db2level reports v9.7 - but you did not specify which fixpack .
    But wrote that your db2-clients are:
    Client Windows Db2 version - 9.5 - (which fixpack?)
    Client Linux db2 version - 9.1 Fixpack 3

    It is wise to ensure that the client db2-version and fixpack are the same same as the server DB2-version and fixpack.
    That is unlikely to be the cause of your current issue, but it will certainly cause other issues over time.
    So update your db2-client software to v9.7 at the same fixpack level as your db2-server when time allows.
  • kanchana0327
    kanchana0327
    16 Posts

    Re: Unable to connect database remotely

    ‏2012-04-25T09:55:57Z  
    • mor
    • ‏2012-04-25T07:53:24Z
    One other thing is that your wrote that your z/linux db2level reports v9.7 - but you did not specify which fixpack .
    But wrote that your db2-clients are:
    Client Windows Db2 version - 9.5 - (which fixpack?)
    Client Linux db2 version - 9.1 Fixpack 3

    It is wise to ensure that the client db2-version and fixpack are the same same as the server DB2-version and fixpack.
    That is unlikely to be the cause of your current issue, but it will certainly cause other issues over time.
    So update your db2-client software to v9.7 at the same fixpack level as your db2-server when time allows.
    Hi Mor

    I have tried to connect the db server on 25thApr-2012(25-04-2012) at 15-00-00 to 15-00-15 and getting the below mentioned logs in the db2diaglog file. Please tell me if you require any more information.

    2012-04-25-15.09.44.504636+330 E494406A436 LEVEL: Info (OS)
    PID : 15516 TID : 2199062662480PROC : db2
    INSTANCE: db2inst1 NODE : 000
    FUNCTION: DB2 UDB, oper system services, sqloOpenMLNQue, probe:4
    MESSAGE : ZRC=0x870F0042=-2029060030=SQLO_QUE_NOT_EXIST "Queue does not exist"
    DIA8558C A message queue did not exist.
    CALLED : OS, -, open
    OSERR : ENOENT (2) "No such file or directory"

    2012-04-25-15.09.44.523943+330 E494843A436 LEVEL: Info (OS)
    PID : 15516 TID : 2199062662480PROC : db2
    INSTANCE: db2inst1 NODE : 000
    FUNCTION: DB2 UDB, oper system services, sqloOpenMLNQue, probe:4
    MESSAGE : ZRC=0x870F0042=-2029060030=SQLO_QUE_NOT_EXIST "Queue does not exist"
    DIA8558C A message queue did not exist.
    CALLED : OS, -, open
    OSERR : ENOENT (2) "No such file or directory"

    Please find the db2 version with fix pack level

    Z- Linux - DB2 v9.7.0.0 - fix pack 0
    windows client - DB2 v9.5.0.808 - fix pack 0
    Unix client - db2 V9.1 fix pack 3

    Note: The current DIAGLEVEL is 4.
  • kanchana0327
    kanchana0327
    16 Posts

    Re: Unable to connect database remotely

    ‏2012-04-25T10:26:30Z  
    Hi Mor

    I have tried to connect the db server on 25thApr-2012(25-04-2012) at 15-00-00 to 15-00-15 and getting the below mentioned logs in the db2diaglog file. Please tell me if you require any more information.

    2012-04-25-15.09.44.504636+330 E494406A436 LEVEL: Info (OS)
    PID : 15516 TID : 2199062662480PROC : db2
    INSTANCE: db2inst1 NODE : 000
    FUNCTION: DB2 UDB, oper system services, sqloOpenMLNQue, probe:4
    MESSAGE : ZRC=0x870F0042=-2029060030=SQLO_QUE_NOT_EXIST "Queue does not exist"
    DIA8558C A message queue did not exist.
    CALLED : OS, -, open
    OSERR : ENOENT (2) "No such file or directory"

    2012-04-25-15.09.44.523943+330 E494843A436 LEVEL: Info (OS)
    PID : 15516 TID : 2199062662480PROC : db2
    INSTANCE: db2inst1 NODE : 000
    FUNCTION: DB2 UDB, oper system services, sqloOpenMLNQue, probe:4
    MESSAGE : ZRC=0x870F0042=-2029060030=SQLO_QUE_NOT_EXIST "Queue does not exist"
    DIA8558C A message queue did not exist.
    CALLED : OS, -, open
    OSERR : ENOENT (2) "No such file or directory"

    Please find the db2 version with fix pack level

    Z- Linux - DB2 v9.7.0.0 - fix pack 0
    windows client - DB2 v9.5.0.808 - fix pack 0
    Unix client - db2 V9.1 fix pack 3

    Note: The current DIAGLEVEL is 4.
    As per your suggestion, I have checked for the routing details and there are no issues. Firewall is disabled in the z/linux.

    and one more information that the port no : 50001 is not getting telnet from the localhost itself.
  • mor
    mor
    577 Posts

    Re: Unable to connect database remotely

    ‏2012-04-25T10:47:12Z  
    As per your suggestion, I have checked for the routing details and there are no issues. Firewall is disabled in the z/linux.

    and one more information that the port no : 50001 is not getting telnet from the localhost itself.
    On the Windows-client, is Windows-Firewall enabled?
    On the Linux-client, is there a software firewall enabled?
  • kanchana0327
    kanchana0327
    16 Posts

    Re: Unable to connect database remotely

    ‏2012-04-26T03:54:21Z  
    • mor
    • ‏2012-04-25T10:47:12Z
    On the Windows-client, is Windows-Firewall enabled?
    On the Linux-client, is there a software firewall enabled?
    No it is not enabled in both clients.
  • mor
    mor
    577 Posts

    Re: Unable to connect database remotely

    ‏2012-04-26T06:58:53Z  
    As per your suggestion, I have checked for the routing details and there are no issues. Firewall is disabled in the z/linux.

    and one more information that the port no : 50001 is not getting telnet from the localhost itself.
    I think it is time to involve your network people,
    because this does not appear to be a DB2 problem.

    If your DB2-client fails to get the acknowledgement
    from your z/linux server (to the SYN sent by connect())
    then the db2-client will timeout the connect. You
    should be able to see this with netstat -a -n on
    the client during the attempted connection.

    Meanwhile, per previous advice, ensure your DB2-clients
    are at Version 9.7 to match your z/linux server.

    Failing that, there's always the awkward alternative of tunnelling along the ssh session.
  • kanchana0327
    kanchana0327
    16 Posts

    Re: Unable to connect database remotely

    ‏2012-04-26T11:03:46Z  
    • mor
    • ‏2012-04-26T06:58:53Z
    I think it is time to involve your network people,
    because this does not appear to be a DB2 problem.

    If your DB2-client fails to get the acknowledgement
    from your z/linux server (to the SYN sent by connect())
    then the db2-client will timeout the connect. You
    should be able to see this with netstat -a -n on
    the client during the attempted connection.

    Meanwhile, per previous advice, ensure your DB2-clients
    are at Version 9.7 to match your z/linux server.

    Failing that, there's always the awkward alternative of tunnelling along the ssh session.
    Ya. sure, will check with the respective team,
    I have got the information that need to set the keepalive parameter for this error code from this link. I don't know how to set this parameter and kindly clarify will it be a problem.

    Ref URl:

    http://www-01.ibm.com/support/docview.wss?uid=swg21164785
  • mor
    mor
    577 Posts

    Re: Unable to connect database remotely

    ‏2012-04-26T11:28:15Z  
    Ya. sure, will check with the respective team,
    I have got the information that need to set the keepalive parameter for this error code from this link. I don't know how to set this parameter and kindly clarify will it be a problem.

    Ref URl:

    http://www-01.ibm.com/support/docview.wss?uid=swg21164785
    That setting is not relevant to your situation, and will not help your symptom.
    You need an established connection before keepalive comes into play.
    Your problem is that you cannot establish a connection in the first place.
    Keepalive is a setting for the workstation tcpip stack, it is not a db2 setting and you certainly should not change keepalive unless you really know what you are doing.
  • kanchana0327
    kanchana0327
    16 Posts

    Re: Unable to connect database remotely

    ‏2012-04-26T12:31:46Z  
    • mor
    • ‏2012-04-26T11:28:15Z
    That setting is not relevant to your situation, and will not help your symptom.
    You need an established connection before keepalive comes into play.
    Your problem is that you cannot establish a connection in the first place.
    Keepalive is a setting for the workstation tcpip stack, it is not a db2 setting and you certainly should not change keepalive unless you really know what you are doing.
    Ya. Thanks a lot for your guidance. Let me check with the connection establishment and get back to you if i need any help.

    Thanks mor !!