ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

ENDTCPCNN in a CL program

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • ENDTCPCNN in a CL program

    Haven't tried in RPG yet, but my CL program that I am trying to write now to end a communications port, will not work. It is crazy because the exact same command works from the command line. In debug the command below gets error message-ID TCP1901 "Internet address 10.62.127.95 not valid." so I copy/paste it onto the command line and it works. I have tried just about everything, the latest being using QCMDEXC to execute the command. Still same result.

    Any ideas?

    ENDTCPCNN PROTOCOL(*TCP) LCLINTNETA('10.62.127.95 ') LCLPORT(54026) RMTINTNETA('10.64.54.133 ') RMTPORT(61725)

  • #2
    I decided to give this a try. The second level text on the message says the IP address must be in the format of nnn.nnn.nnn.nnn, so I decided to hard code my IP address that I am testing with to '10.62.127.95' and that worked! So now I have to figure out how to convert that number from 10.64.127.95. Is there any command or API that would do that form me? I guess I could write my own (heading that way). any advice is much appreciated!

    Comment


    • #3
      I don't understand. What is the difference between the one that worked and the one that did not? You asked for a way to convert between them, but I don't see the difference.

      Comment


      • #4
        There is no difference between me prompting the command from the command line and what I see when I run the CL program in debug and view the value of the command string (I am using QCMDEXC to execute the command). That is my question? What exactly is the difference? Whatever it is you cannot visually see anything different. When I tried the nnn.nnn.nnn.nnn format the CL program executes the command successfully. But, I am not an IP expert, so I am not sure if there is a safe way to convert, for example, 10.62.127.95 to 010.062.127.095, or 10.64.54.133 to 010.064.054.133. Or should I use *UDP instead of *TCP. I am missing something....

        Comment


        • #5
          I see. So when you say "nnn.nnn.nnn.nnn format" you mean that you're padding each octet of the address with leading zeroes to make it occupy 3 digits. I am very skeptical that this makes a difference. (I know of many cases where this has turned out to be harmful -- though it may not be harmful in this case.)

          As for *UDP and *TCP these are two different network protocols. While they both have port numbers associated with them, the port numbers are separate. So you can have both a TCP port 1000 and a UDP port 1000, they are two different ports even though they are the same number, because they are different protocols. It's sort of like my name is Scott, and I have a friend whose name is also Scott... even though we have the same name, we are different people. Even though TCP port 1000 is the same number as UDP 1000, they are two different things that just happen to have the same number.

          So you need to know if it's a TCP or UDP port that you are closing. UDP does not maintain an ongoing connection like TCP does, so it seems unlikely tht you'd need to close a UDP transmission in this fashion, unless the goal is to force a listener to stop? A starting point is to look at the connection when it is functioning normally (and doesn't yet need to be ended) and see if it is TCP or UDP. Then treat it as the same.

          With regards to the underlying problem, I haven't run into it myself, and I don't have your code. I wonder if it could be the trailing blanks after the address in your command strings? I wonder why you are using trailing blanks like that? (But this is just a guess.)

          Comment


          • #6
            Thanks Scott. I borrowed a program from Think400.com that copies the NETSTAT data to a report. I modified it to populate a work file in QTEMP, and the work file is what I am reading to find the ports that are in question. I did try trimming the blanks, but it had no positive impact. I appreciate your comments. Thanks again.

            Comment


            • #7
              I tried writing some CL programs to reproduce the problem (I did not look at the one from Think400) but wasn't able to. Everything I tried worked perfectly -- this is with deliberately trying to make it fail.

              In order to help you further, I'm going to need your code and precise steps that are needed to reproduce the problem.

              Comment

              Working...
              X