General Net Installation Check
The Ingres Net installation check is a diagnostic procedure that checks your installation to determine the following:
• Whether the problem is Ingres Net-related
• Whether the iigcn and iigcc processes are running
• Whether the network protocol software is working
How You Check Net Installation on Windows
If you are experiencing a problem and cannot determine its source, use this diagnostic procedure as a starting point:
1. Verify that your network protocol is functioning.
a. Use the ping command to connect between machines to verify that basic TCP/IP networking is working.
b. On both the client and the server, verify that TCP/IP is properly installed and configured. Do this by attempting to connect to the default localhost (or loopback) listen address from each machine. Type one of the following commands to loop back to your own machine using the network:
• ping localhost
• ping 127.0.0.1
• ping ::1 (if TCP/IP version 6 enabled)
If either “a” or “b” fails, the problem is with the underlying network. Contact your network administrator.
2. If the remote node is a Linux machine, verify that you can connect to the target database on the remote node when you are logged in directly to the remote node.
a. Use telnet to log in to the remote node from your local node.
b. Enter a command that connects you to the database. For example:
sql database_name
If you cannot connect to the database even when logged in directly to the remote node, the problem is something other than Ingres Net.
If you can connect this way, but cannot connect when you are Using Net to log in to the remote node and connect (through the syntax sql vnode_name::database_name), it is an Ingres Net problem. Proceed with Step 3.
3. Check that the iigcc process is registered with the Name Server:
a. Enter iinamu at the operating system prompt.
b. Type show comsvr.
If you receive no output from the show comsvr command, this means that no Communications Server is registered with the Name Server.
4. Check that configuration parameters such as local_vnode and the Communications Server listen address are correctly set. These parameters can be viewed and, if necessary, changed using the Configuration Manager (vcbf) or Configuration-By-Forms (cbf) utility.
5. Check the II_GCNxx_PORT environment variable where xx is the instance ID. It must be visible only when using the ingprenv utility. It must never be visible when using the Linux commands env or printenv. II_GCNxx_PORT must not be part of your local operating system environment. If it is set in the local environment, it overrides their proper settings in the Actian X symbol table.
You must be the installation owner (who by default has Actian X user privileges) to take corrective action.
How You Check Net Installation on Linux
If you are experiencing a problem and cannot determine its source, use this diagnostic procedure as a starting point:
1. Verify that your network protocol is functioning.
a. Use the rlogin and/or telnet commands to connect between machines to verify that basic TCP/IP networking is working.
b. On both the client and the server, verify that TCP/IP is properly installed and configured. Do this by attempting to connect to the default localhost (or loopback) listen address from each machine. Type one of the following commands to loop back to your own machine using the network:
• telnet localhost
• telnet 127.0.0.1
• ping ::1 (if TCP/IP version 6 enabled)
The login messages that follow the command reveal whether you are connected to your own machine (the name of the machine can be embedded in the messages). If they do not, you can log in and issue the hostname command to display the name of the machine to which you are connected.
If either “a” or “b” fails, the problem is with the underlying network. Contact your network administrator.
2. Verify that you can connect to the target database on the remote node when you are logged in directly to the remote node.
a. Use telnet, rlogin, or your site’s network server bridge software to log in to the remote node from your local node.
b. Enter a command that connects you to the database. For example:
$ sql database_name
If you cannot connect to the database even when logged in directly to the remote node, the problem is something other than Ingres Net.
If you can connect this way, but cannot connect when you are Using Net to log in to the remote node and connect (through the syntax sql vnode_name::database_name), it is an Ingres Net problem. Proceed with Step 3.
3. To verify that the Communications Server (iigcc) and Name Server (iigcn) processes are running on your local node, use the ps command. This command shows the status of all currently running processes. Also check the processes on the remote node.
4. Check that the iigcc process is registered with the Name Server:
a. Enter iinamu at the operating system prompt.
b. Type show comsvr.
If you receive no output from the show comsvr command, this means that no Communications Server is registered with the Name Server.
5. Check that configuration parameters such as local_vnode and the Communications Server listen address are correctly set. These parameters can be viewed and, if necessary, changed using the Configuration Manager (vcbf) or Configuration-By-Forms (cbf) utility.
6. Check the II_GCNxx_PORT environment variable where xx is the instance ID. It must only be visible using the ingprenv utility. It must never be visible using the Linux commands env or printenv. II_GCNxx_PORT must not be part of your local Linux shell environment. If it is set in the local environment, it overrides their proper settings in the Actian X symbol table.
You must be the installation owner (who by default has Actian X user privileges) to take corrective action.