calling another system using IP and port

I believe the CICS box is a mainframe.  Can you find out if a webserver is even running on the box?  If so, then try to bring up any page from the CICS box.  That will be the first step to debug it.  

No application is running on IP address 19.140.3.1 that is listening on port 54555, or some firewall could be blocking the request from your machine to the specified IP address.

trying to inderstand the scenario. Is 19.140.3.1 the IP of some application or the CICS (mainframe) box itself?
thanks

It is the IP address of the target system to which the connection request is being sent...

This command may help you figure out what it actually is:


nslookup 19.140.3.1

Your application is expecting to find an HTTP server running at 19.140.3.1 on port 54555.  When your application attempts to open a TCP connection to this service, the connection attempt fails.  

The fact that it is a "CICS box" probably means exactly nothing - at least when it comes to this problem.  

You're application is trying to connect to a web service, not CICS.  You're getting the "Connection refused" message because your application cannot successfully connect to that remote web service (or there's no web service running on that port).  

By the way, it looks like this IP address is owned by Ford Motor Company and is located in Dearborn Michigan.

There are numerous possible causes:

1) The remote system or application is performing some sort of filtering, and decided to reject your connection attempt for some reason.  Contact the remote application administrator and determine if authorization or registration is required to access this service.  This is a very likely cause.

2) The remote system is not responding quickly enough, and the connection attempt is timing out.  If this is happening, you'll typically see a message later in the stack trace.  Contact the remote system administrator to determine if there is a problem with the availability of the remote service, or modify your application to increase the connection timeout.

3) The remote application is not currently running (or is running, but on a different port).  Contact the remote system administrator for assistance.

4) A firewall or other network device is blocking the connection.  Contact your local network administrator and the remote network administrator for assistance in gaining access to the remote service.

Questions and suggestions:

- Are you sure the IP address and port are correct?

- Are you connecting to this system locally (same subnet) or remotely?  

- Is there a firewall, filtering router, or a VPN between your system and the remote host?

- Have you ever been able to access the remote service before?

- Attempt to PING and TRACEROUTE from your system to the remote system, and post your results here.

- If you'll explain what your application is doing (or attempting to do), we might be able to provide more focused troubleshooting assistance.

- Gary Patterson

Excellent Gary.  That's a good article for anyone who has the "something is not connecting" issue.  Any luck royjayd?  Sounds like a security issue.  Are you sure you have the right credentials?  Do you have the API for the call?

Thanks Gary and others
How can I ping and traceroute from my system?
Will the ping check if port on that ip is active?

I am using windows xp system
Thanks

also i did a nslookup

C:\>nslookup 19.140.3.1
Server:  np555c2n1.lotus.com
Address:  160.74.115.2

*** np555c2n1.lotus.com can't find 19.140.3.1: Non-existent domain

guys for security reasons i cannot give the exact IP which i am trying. 19.140.3.1is a example IP.
Can anyone explain what the nslookup command above did?
I am guessing its not finding somehting?
thanks

try:

traceroute -p 54555   19.140.3.1

http://en.wikipedia.org/wiki/Traceroute

ping 19.140.3.1

Here's some online tools the might help:

http://network-tools.com/

This talks about your error:

http://support.microsoft.com/kb/200525
http://www.windowsnetworking.com/articles_tutorials/Using-NSLOOKUP-DNS-Server-diagnosis.html

Info about record types:

http://en.wikipedia.org/wiki/List_of_DNS_record_types

C:\>traceroute -p 54555   19.140.3.1
'traceroute' is not recognized as an internal or external command,
operable program or batch file.

Doh.  I mean nslookup, not traceroute.  And you had already done it before my post.  Looks like it's there try telnet just to see if it picks up:

telnet <ip>  <port>

You wont be able to get a response unless telnet is running on the host for the port, but if you don't get an error, then that port is listening and it's probably a security issue.  What type of security does it have?

Use this page if you don't have things installed:


http://network-tools.com/ 

No idea why developedtester advised to do an nslookup.  nslookup is a tool used to help resolve DNS problems.  Since you are not using DNS (you already know the IP address that you're trying to connect to), nslookup is a waste of time.  Forget about it.

In Windows, open a command prompt, and type

PING x.x.x.x

Where x.x.x.x is the numeric IP address of the remote system.   This will tell you if you can even establish a basic IP connection to the remote system.  If you get responses back, then you at least have verified that you can connect using the ICMP (PING's protocol) protocol.  There is still no guarantee that you can attach to a specific TCP service running on a specific port.  PING is just a good place to start.  If you cannot PING an IP address, it means that the host is either unavailable (offline, shut down), or that there is a firewall or other network filtering in place between you and the remote host, and you can stop wasting your time and ask for help from either your local network administrator, the remote administrator, or both in order to establish connectivity to the remote system.

If you cant' PING, try issuing a traceroute.  The Windows command is:

TRACERT x.x.x.x

(No idea where the "-p" option listed by developedtester comes from.  Suspect he/she just made it up.  Traceroute is not a TCP tool, and is certainly not port-specific.  Tracert issues ICMP packets, like PING).

This command, in essence, attempts to PING each router between you and the remote host, and if a remote system is unreachable, it can sometimes tell us about where in the route the connectivity issue lies.  Again, it does not use TCP, but ICMP, so there is no guarantee that if you can trace the route that you'll be able to connect to a specific service.

Finally, you were advised to attempt to connect with TELNET.  It is a good idea, but developedtester says "You won't be able to get a response unless telnet is running on the host for the port"...

That's not correct.  We're not looking for a Telnet server.  We're looking for a HTTP server, and the good news is that with a little basic knowledge of the HTTP protocol, you can use a telnet client to test connectivity to an HTTP server.

Follow these specific instructions (note that the instructions tell you to telnet to port 80.  In your specific case, you want to telnet to port 54555, since that's where the HTTP server is supposed to be according to your initial question.)

Test HTTP via Telnet Client
http://www.esqsoft.com/examples/troubleshooting-http-using-telnet.htm

Also, please go back and answer each of my questions.

Now that I know you posted a false IP address (please don't do this: I wasted time trying to diagnose the connection to that particular system.  If you need to obscure an address, tell us that right up front), I have one additional question:

Is the remote address a PUBLIC IP address on a different network, or a PRIVATE IP address on the SAME network as your system?  If you aren't sure, post the first two digits of each IP address, and we can make an informed guess.

- Gary Patterson

I'm not meaning to be harsh about developedtester's advice.   I'm sure that he/she is just trying to help.  Problem is, incorrect advice can really confuse the issue.

Anway, developedtester and I agree on one thing:  this is probably a security or firewall issue, and you probably can't solve that without the help of the remote network or system administrator and/or your local network administrator.  You need to get them involved right now.

You'll probably save a lot of time if you perform the PING, TRACERT, and TELNET tests that I've described, and copy the results to both administrators when you ask for help.  ANd make sure you give them the REAL addresses involved.

Also, what happens when you just open up a browser and put in that URL?  I expect that you'll get an error or timeout there, too, but if not, it might be useful in diagnosing the original problem.

http://x.x.x.x:54555

- Gary Patterson

Thanks Gary for taking the time and responding.
I am going to execute the commands, talk to cics
Admin and get back to you. The problem is I am in the java
Team and cics admin belongs to cics team so it takes
Time to get response from him.

Happy to help.  Post back if you need additional assistance.

- Gary Patterson

I was on an old "tranceroute" man page which had:

-p     Set the base UDP port number used in probes (default is  33434).
              Traceroute  hopes that nothing is listening on UDP ports base to
              base  +  nhops  -  1  at  the  destination  host  (so  an   ICMP
              PORT_UNREACHABLE message will be returned to terminate the route
              tracing).  If something is listening on a port  in  the  default
              range, this option can be used to pick an unused port range.

Sorry for the confusion.  This isn't an option anymore.  

ran the ping and tracert
should it be
'telnet 19.140.3.1 54555   ?

thanks

Everything works great now, Thanks very much.
Any help with my next question will be greatly appreciated
https://www.experts-exchange.com/questions/27037666/unix-scheduling-tasks.html