Connect:Direct in the family

Day 1

You have to help family and friends. So the scene was set on that Friday the 13th. I’m not superstitious by the way! I received an urgent email from my brother Lee in the United States asking if I could help him with a Connect:Direct (C:D) connection between his company and another. He didn’t know anything about C:D apart from that I knew a lot more than he did.

He had received some good information from his corresponding number in the other company that he was trying to connect to. The problem was that they had given him too much information, and that it didn't make much sense to him. Lee’s C:D was on a Windows machine, and the box he was trying to communicate with was running the UNIX version of C:D. My brother saw no correlation between the configuration items he had been given and the C:D for Windows that he had.

The fact that the two C:D’s were running on different platforms was also thought to be part of the problem. I reassured my brother that this was normal for C:D UNIX to communicate with C:D for Windows or C:D for mainframe etc.

Learning anything new can be daunting. The trick is to not try to take everything in at once. In this case Lee really didn’t need to worry about all the configuration parameters he had been given as most of them were defaults. The key thing he needed to think about was exchanging the right information with his 3^rd party in order to make the connection.

Lee had been given a node name, an ip-address, a port number, a user name and a destination directory to copy files to.

It is important to ensure that you have network connectivity before trying to configure C:D as you can spend a lot of time before realising that there is nothing wrong with the C:D configuration, and that you had a network issue from the start. There may be firewalls that have to be navigated that may perform NAT (Network Address Translation) etc. So you need to be sure that the ip-address being used for you to put in your configuration is an address that you can “see” from your C:D server. There is no point specifying an address that can not be routed to.

At my work we can test the connectivity using a perl script. Lee didn’t have perl on his Windows machine and wasn’t in the mood to install it at that time. I explained that he could use the “telnet” program to open the appropriate port on the remote server to just see if there is anything listening on that port. I told him to type in “telnet 192.168.9.9 1364” at the Windows command prompt.

There are 4 possible outcomes from running this command “failed”, “refused”, “timeout” & “connected”. I told him that we needed to be able to prove the connectivity to the remote node before continuing.

In the next post I help Lee configure his C:D for Windows using the Requester program.