Verifying iCluster Communications

Share on Facebook0Share on Google+0Tweet about this on Twitter0Share on LinkedIn0Email this to someoneShare on Reddit0

When communications go down between systems in your network or a system goes down, the first test when everything is back up again is a simple PING <node name> command. This will tell you that at least TCP/IP is up and running on the node that went down and your current node can find the other nodes. However simple TCP/IP verification may not be enough. If you start up a replication group and nothing seems to be happening, there may be other factors in play, for example the iCluster listening job DMCHATL may not be running in the XDMCLUSTER subsystem, or the entire subsystem may be down. You could verify this by signing into the node with issues, but an easier way to determine if iCluster communications are up and running is by using the HAPNGTCP.

Think of HAPNGTCP as PING for HA. The HAPNGTCP command first asks for the remote host name which can be either the system name or the IP address. It then asks for the remote port, usually 4545 but check for the “dmcluster” entry in the service table entries using WRKSRVTBLE SERVICE(‘dmcluster’). This should be enough to determine if communications are running. There are other parameters which give a good indication of what the command is checking, such as the remote product library (ICLUSTER by default) and the job description (by default CSJOBD) as shown below:

HAPNGTCP1

Once the command is entered you will end up in a terminal session. Don’t Panic! As long as you see something like the screen below you are good to go.

HAPNGTCP2

If you receive an Open failure message or Connect failure message – you have problems. Check to make sure you typed the correct node name or IP address, and also check to ensure IP is actually up and running. If necessary prompt the command and ensure that the product library and job description are correct.

Once done, just press Enter to exit the command.

The following two tabs change content below.

iCluster Tech Tuesday

iCluster TechTuesday is a set of posts covering technical tips and techniques to help get the most out of your Rocket iCluster installation.

, , ,

One Response to Verifying iCluster Communications

  1. Chris Jackson August 6, 2015 at 12:20 pm #

    HI
    What would you expect a ‘reasonable’ response time to be?

    My initial one took 3 seconds to open and connect. Is this normal?

    thanks

    open time = 3.100 (secs)
    connect time = 3.133 (secs)
    send/recv control time = 0.004 (secs)
    send/recv data time = 0.004 (secs)
    send/recv data time = 0.004 (secs)
    send/recv data time = 0.004 (secs)
    send/recv data time = 0.004 (secs)
    send/recv data time = 0.004 (secs)
    send/recv control time = 0.004 (secs)

    better responses
    open time = 0.913 (secs)
    connect time = 0.388 (secs)
    send/recv control time = 0.010 (secs)
    send/recv data time = 0.004 (secs)
    send/recv data time = 0.004 (secs)
    send/recv data time = 0.004 (secs)
    send/recv data time = 0.005 (secs)
    send/recv data time = 0.004 (secs)

    open time = 0.938 (secs)
    connect time = 0.222 (secs)
    send/recv control time = 0.004 (secs)
    send/recv data time = 0.004 (secs)
    send/recv data time = 0.005 (secs)
    send/recv data time = 0.004 (secs)
    send/recv data time = 0.005 (secs)
    send/recv data time = 0.004 (secs)
    send/recv control time = 0.004 (secs)

Leave a Reply