Introduction

Communications failures between the enterprise console and your IBMi are going to fall into two categories;

  1. Misconfiguration within the Halcyon software.
  2. Network - either a failure or a misconfiguration.

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.

Misconfiguration within the Halcyon Software

You should work through the following steps in order and double-check them.

Check the device manager entry for the IBMi on the Enterprise Console.

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

or

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;

  1. Issue the ENDMON command to stop monitoring.
  2. Use option 2 “Change” against the *SYSTEM entry to change it to the appropriate values.
  3. Issue the STRMON command to start monitoring.

Check the Remote Location entry for the Enterprise Console on the IBMi

GO HALCYON > WRKRMTLOC 

or

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.

DNS resolution

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.

Check DNS resolution on the Enterprise Console.

Open a command prompt on the Enterprise Console and issue the command;

nslookup hostname

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.

nslookup IP_ADDRESS

Check DNS resolution on the IBMi

On your IBMI issue the command;

NSLOOKUP HOSTNAME(‘HOSTNAME’)

And reverse lookup;

NSLOOKUP HOSTNAME(‘IP_ADDRESS’)

Remedying DNS resolution

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;

Windows: %SystemRoot%\System32\drivers\etc\hosts

10.72.73.59 HAL720P9 HAL720P9.HALCYON.LOCAL

IBMi:

If you do this, then check the host name search priority is set to *LOCAL on the IBMi.

CFGTCP > Option 12

or

CHGTCPDMN (F4)

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.

Checking the route between the Enterprise Console and the IBMi

NB: “ping” may not be permitted on your network.

Enterprise Console to the IBMi

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.

IBMi to the Enterprise Console

Check that you can ping the Enterprise Console from the IBMi. Issue the command:

PING RMTSYS(‘HOSTNAME’)

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;

PING RMTSYS(‘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.

Check that the TCP port is connecting

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.

Checking traffic from the Enterprise Console to the IBMi

Open up the Enterprise Console on the Enterprise Console Server.

  1. In the devices panel select the IBMi by clicking it once with your mouse pointer.
  2. Click the Details tab.
  3. See if the scroll bar expands…

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.

Checking traffic from the IBMi to the Enterprise Console

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.

Diagnosing port problems on the Enterprise Console

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.

Attempt to connect to the IBMi on port 15000 using TELNET from the Enterprise Console.

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:

then either:

  1. Halcyon is not started on the IBMi.
  2. The port is not open for outbound traffic on the Enterprise Console.
  3. The port is not open for inbound traffic on the IBMi.

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.

If telnet is not available

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>

Then type:

$PSVersionTable.PSVersion

Then use:

test-netconnection hostname -port 15000

Here’s an example of a positive and a negative result…

Diagnosing port problems from the IBMi

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:

  1. The Halcyon services are not operational on the target Enterprise Console.
  2. The outbound port is blocked for the IBMi.
  3. The inbound port is blocked for the Enterprise Console.

Attempt to connect to the Enterprise Console on port 15000 using TELNET from the IBMi.

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;

  1. The Halcyon Network Manager Server was not started on the target Enterprise Console.
  2. The traffic could not get through due to a firewall or port.
  3. The Windows Firewall on the Enterprise Console is turned on.

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.

Network Address Translation (NAT) appendix

Let us assume the following:

  • Enterprise Console (ENTCON) has a physical IP address of 192.168.2.41
  • Enterprise Console (ENTCON) has a NAT IP address of 172.16.1.19
  • IBMi (SYSTEMA) has a physical IP address of 172.24.195.22
  • IBMi (SYSTEMA) has a NAT IP address of 74.218.145.125

If you are using NAT on your ENTCON, do the following:

  • • Configure the ENTCON Device Manager entry to have the host/address as the physical IP address (192.168.2.41)

  • Find the following file on the ENTCON: %ProgramFiles%\Halcyon\Network Manager\NMService.alt
  • Edit this file using notepad and add the ENTCON NAT address as a single line entry.

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.

  • Next, add the ENTCON NAT address as an IP address mapping on the IBMi:
  • GO HALCYON > 42 > 6 > F6 or GO HALCYON > WRKIPAMAP > F6
    • Set the primary IP address as the ENTCON NAT IP address:

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.

Last Modified On: May 29, 2020