Communications failures between the enterprise console and your IBMi are going to fall into two categories;
If the communications link was working fine and then suddenly it has failed or is not working, chances are you have a problem with your network – Usually this will be either an equipment failure or someone has introduced a firewall rule blocking the ports, so you should check this first.
If you are setting up a new communications link and it just doesn’t work, then the first place to look is for a misconfiguration within the Halcyon software, then look to the network.
You should work through each step in this “how to…” in order from the start, to methodically check each item is working correctly.
NOTE: If you are using Network Address Translation (NAT) on your network for either the Enterprise Console or your IBMi, then you should refer to the appendix on this FIRST.
You should work through the following steps in order and double-check them.
It is important that the Name field in device manager entry MATCHES the IBMi System name EXACTLY.
It is also important that the device type correctly specifies “Power/System I”
Under Advanced > Settings, check that the “Connect On Port” field matches the “*SYSTEM” entry Port in the “Work with Remote Locations” on the IBMi
GO HALCYON > WRKRMTLOC
GO HALCYON > 42 > 4
If the port or IP address are incorrect in the *SYSTEM entry on the IBMi, you need to do the following;
GO HALCYON > WRKRMTLOC
GO HALCYON > 42 > 4
Ensure that the IP or Hostname specified for the Enterprise Console matches what is configured in Device Manager for the Enterprise Console.
If you have configured hostnames (which is the preferred method) you will be using DNS. You need to ensure that DNS is resolving correctly. This is important especially if your Enterprise Console and IBMi are resident in different domains.
Open a command prompt on the Enterprise Console and issue the command;
The name server should return the IP address of the IBMi. This IP address MUST match the “*SYSTEM” entry in the “Work with Remote Locations” screen on the IBMi.
Perform a reverse lookup to ensure the IP address resolves back to the hostname.
On your IBMI issue the command;
And reverse lookup;
If Hostnames and IP addresses fail to resolve correctly you should speak to your DNS administrator and get the DNS entries corrected, then re-try the procedure above.
Alternatively, a quick way to bypass DNS temporarily would be to ensure there are suitable hostname entries in the host tables for the Enterprise Console and IBMi.
Remember to add both the short hostname and the fully qualified domain name to your entries. E.g;
10.72.73.59 HAL720P9 HAL720P9.HALCYON.LOCAL
If you do this, then check the host name search priority is set to *LOCAL on the IBMi.
CFGTCP > Option 12
If it is set to *REMOTE, then it will resolve first through the DNS server, if you change it to *LOCAL it will resolve hostnames from the host table first.
Changing this may affect applications on your IBMi, so proceed with caution.
NB: “ping” may not be permitted on your network.
Check that you can ping the IBMi from the Enterprise Console using the hostname. Open a command prompt and issue the command:
ping hostname -n 5
If this fails with “ping request could not find host” then the name is not resolving correctly either from DNS or from the host file. You should re-check those.
Then try using the IP address;
ping IP-ADDRESS -n 5
If either method fails with “Destination host unreachable” then the Enterprise Console cannot reach the target host or IP address. You should consult with your network team to resolve this.
Check that you can ping the Enterprise Console from the IBMi. Issue the command:
Remember that not all of the response messages will be shown so you should follow up with;
DSPJOBLOG > F10 > F18
If this fails with “Unknown host, HOSTNAME” then the hostname is not resolving correctly either from DNS or from the hosts file. You should re-check those.
Then try using the IP address;
If either method fails with “No response from host within 1 seconds for connection verification n” then the Enterprise Console cannot reach the target host or IP address. You should consult with your network team to resolve this.
Once we have established that there is a route between the Enterprise Console and the IBMi, using ping, we now need to check to see if traffic is allowed through on the correctly configured port.
The Enterprise Console ALWAYS uses TCP port 15000. This cannot be changed at present.
The IBMi port can be configured, but the default is port 15000. For the purposes of this document we will be using port 15000 as well. If you are using a different port, then substitute your port number appropriately.
Open up the Enterprise Console on the Enterprise Console Server.
When we select the device in the devices panel, the Enterprise Console sends a “getsysinf” command to the IBMi. If this is returned successfully, we will see the details panel fill with data and you will be able to scroll down.
You can see the request on the IBMi (IF it gets through) by issuing the DSPNETLOG command
Look for an “RCV” (Received) entry from your “ENTCON” location (or whatever it is defined as in your remote locations). Use option 5 (Display) to view the entry and see that it has the “getsysinf” request in it.
Immediately below the “RCV” entry should be a “SND” (Send) entry, which is the IBMi responding to the request.
If this has a Status of “Sent-Ok” and you can see the Enterprise Console detail panel update, then we have two-way communication on the TCP port defined and all is good.
Use option 5 (Display) to view the entry and see that it has the “getsysinf” data in it.
Use the command SNDCONMSG to send a console message:
HALPROD/SNDCONMSG MSG('Halcyon test') LOCATION(ENTCON)
Use DSPNETLOG to see the message being sent.
Option 5 (Display) will show the data – look for the text you specified in the message.
Ensure the message arrives at the Enterprise Console.
If this works, you have a good communications link from the IBMi to the Enterprise Console.
If either of these don’t work use the next steps.
If you cannot get two-way communications working it is most likely that the port is blocked at your firewall. This is what occurs in 99% of cases.
The firewall could be the Windows firewall on the Enterprise Console. It could be your domain firewall and if you are an MSP, and the IBMi is located at a customer site, it could be the firewall at the customer end, so please check with your network teams first.
Remember the ports need to be open for traffic in BOTH directions (inbound and outbound).
The software is very simple – it can either connect or it can’t. If it cannot connect then the problem is very likely going to be a firewall blocking the traffic.
If you are convinced that the ports are open, you can use the following methods to diagnose the fault.
Ensure that Halcyon is started on the target IBMi. Then, on the Enterprise console server, open a command prompt and issue the command; telnet hostname 15000
This assumes the “telnet” command is available – if it is not, see the next chapter.
When you press Enter, the screen will go blank for a few seconds and then, if the telnet command successfully connects to the socket on port 15000 you will see something similar to the screen below:
This will also generate a RCV entry in the network log thus:
If you get the following response:
You can, if this fails, change the port number on the IBMi for the *SYSTEM entry using the procedure on page 3. You can then attempt to connect using a different port number. You will need to change the device manager entry for the IBMi as well if you intend to remain with the changed port number.
Starting from windows 7, the telnet client is a feature that must be installed, so it is not always available. However, within Powershell 4.0 and above you can use the test-netconnection command.
Check the powershell version by starting powershell….
Press the windows key and type “powershell” <Enter>
test-netconnection hostname -port 15000
Here’s an example of a positive and a negative result…
If you use a SNDCONMSG as described previously and you check the Network Log using DSPNETLOG and the SND is in a Send-Wait, like this:
then the transmission is not getting through, either because:
Ensure that the Halcyon Services are started on the Enterprise Console. On the IBMi issue the command:
TELNET RMTSYS(ENTCON) PORT(15000)
TELNET attempts to connect to the active port on the enterprise console. It will take approximately 60 seconds to time out. If the connection attempt gets through then, you will see the following response in the joblog:
If you see the following response in the joblog, which will take 2 minutes to time out (so please be patient) then the connection attempt failed because either;
If the traffic cannot get through, check to see if there is a port restriction configured on the IBMi:
CFGTCP > option 4
If the traffic cannot get through and you have completed all previous steps, then the problem is the port is being blocked by a firewall.
Let us assume the following:
If you wish to add subsequent IP address (alternate NAT address) to this file, add one per line thus;
Once you have added the NAT entries (and every time you change this file) you must restart the Halcyon Network Manager Service. This will cause any connected Halcyon consoles to drop and will require to be re-connected.
Press <Enter> and add the ENTCON Physical address as the “Alternate IP address”:
Press <Enter> to save the configuration.
Now the IBMi knows that any communications received for Halcyon from 172.16.1.19 are from 192.168.2.41.
Still have questions? We can help. Submit a case to Technical Support.