× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



OK,

I tried telnet with the socket server running.  It just waits.  If I hit
enter, i get the message:

Connection to host lost.


It seems the server program is waiting/listening.   Unfortunately, I did not
write either the server or the client program.  It is a product supplied
with our ERP system.   I'll see what I can work out with them.   Looks like
the network is ok.

Thanks again for the help,

-jose a.
-----Original Message-----
From: Scott Klement [mailto:klemscot@klements.com]
Sent: Thursday, June 06, 2002 11:32 AM
To: midrange-l@midrange.com
Subject: RE: Sockets



On Thu, 6 Jun 2002, Rodriguez, Jose Amable wrote:
>
> Is there anything I have to do to the services table (under tcpadm) so
that
> I can configure the port for telnet.

You aren't trying to enable telnet on that port.   That would defeat the
purpose of the whole test.

The idea of the testing was:

     1) To see if your system is responding to basic IP function, by
            trying to ping it, and see if it responds.

                  ping x.x.x.x

     2) If it does respond, check to see if TCP works over IP by
            using a tested, known good, program like IBM's telnet
            server.

                  telnet x.x.x.x

     3) If that worked, then see if the custom-written TCP server
            is listening for connection requests.   We use a telnet
            client because we want to make sure the program we're
            testing it with is known to be working.  (It doesn't
            do us much good to test a program that may or may not
            be working by using another program that may or may not
            be working... we just end up with more questions that way)

            We use a telnet client to test it because we know that it
            worked in step 2.   But, we're not trying to create a
            telnet session -- we're trying to test the custom server
            program in question.    The way we tell the telnet client
            to connect to the custom server instead of the IBM telnet
            server is by telling it a different port number.

            So, if for example, the custom server program listens
            on port number 8026, we'd do:

                   telnet x.x.x.x 8026

>
> The reason I as is that I tried telnet x.x.x.x portno and I get the
message:
>
>       Connecting To <HOST>...Could not open a connection to host on port
> <portno> :
>       Connect failed


You do NOT want to change the services table.   Changing the services
table would make IBM's telnet server run on the new port (after it has
been restarted)

That's not the goal here.   The goal is to test the custom server program
to see if it's working.

Consequently, we leave the services table alone, and type:

          telnet x.x.x.x 8026

(or what ever the port number is supposed to be!)

Now, if we get a "Connect failed" it can mean one of two things:

        1) A firewall is blocking that port, so we can't get to it.

        2) The custom server is not listening for requests.
            (This could be because it's not running, or it could be
            that it doesn't work)

>
> I also tried adding a telnet entry in the services table and removing the
> other one. That is:
>
> telnet <portno> tcp
> telnet <portno> udp
>
> What do I do next???

Unless you intend to change which port your AS/400 uses for normal telnet
operations, I'd change that services table back to port 23.
Otherwise, it's going to cause major problems.

Hopefully, you understand now what you're trying to accomplish.

Are you the person who wrote the custom server that you're trying to test?
If so, maybe you should take a look at the bind() and listen() statements
in your code.   Make sure that they are working correctly...

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.