Question : RPG Socket Program Hanging on Connect()

First, I am new to socket programming. I found a great tutorial online and am reusing code from it. I am using a socket program to send hex commands to a production scoreboard. The hex commands increment/decrement counters, etc on the board.

In my socket program, I send the binary/hex commands to various 8 input ports for the board to process. In this example, I am using software to send the binary command to simulate input 1 (total count). The socket program randomly will return an error that it could not connect to the host.

Ex:

I can run my program 70x within a minute or so and it increments the total counter 70x. Everything is fine. Then, out of nowhere, when called, the program tries to make a connection on port 4001 and it hangs. It then returns an error stating it could not make a connection to the host within the timeout period.

As for working/not working, it appears completely random. I can create the socket, send, and close the socket several times and all is fine. I may then wait 3 minutes and send, and the program hangs on the connect function. Any ideas?

thanks in advance - Adam

         
           
             1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:

           
           
          eval      sock = socket                       
             (AF_INET: SOCK_STREAM:IPPROTO_IP)

if        connect(sock: p_connto: addrlen) < 0   
eval      err = errno                            
callp     close(sock)                            
callp     die('connect(): '+%str(strerror(err))) 
return                                           
endif                                            

eval      rc = Send(sock: %addr(activeCmd):4:0) 
                                                
if        rc < 4                                
eval      err = errno                           
callp     close(sock)                           
callp     die(%str(strerror(err)))              
return                                          
endif                                           

eval      rc = Recv(sock: %addr(activeCmd):4:0) 
e anything if no bytes returned                 
if        rc < 1                                
callp     close(sock)                           
callp     die(%str(strerror(err)))              
return                                          
endif

           
         

Answer : RPG Socket Program Hanging on Connect()

As far as the batch NEP that relays, I really like the sound of that, but do not know what it is.

Sorry... NEP -- Never-Ending Program.

Basically, it's a program that you submit to run in some batch subsystem and that is expected to loop forever. (Well, until some kind of command or signal tells it to end.) You might submit it to job queue QSYSNOMAX to run like various server programs.

Your program would start by opening the socket connection. Then it would sit while waiting for an entry to arrive on a data queue. Whenever an entry appeared, it would send it across the socket and go back to see if another entry was on the data queue.

It might spend 99.999% of its time just waiting. Any number of programs from other jobs could be sending commands to the single data queue.

If necessary, the data queue could be keyed so that every command had a unique identifier, perhaps derived from the GENUUID API. When a command is pulled from the queue and sent out the socket, the unique ID is used to send an acknowledgment back through the data queue. Only the sending job would know which key was the acknowledgment for it. The data queue would provide two-way communication between your jobs and your "socket server".

If the volume was so much that your server couldn't keep up, you'd simply start a second one.

The "socket server" would have everything needed to do your sockets work. It wouldn't have any complications from needing to understand the commands from the data queue -- it just sends whatever shows up. Keep the logic focused in nicely separated proc, modules and programs -- neat division of labor.

Your "client programs" will also be simple. All they do is handle the appropriate command strings and send them to the data queue. (Optionally, it's a two-way data queue; but that might be a later enhancement. Make it work, then make it better.)

If you haven't used data queues, you should find them much easier than sockets.

Tom