Every now and then someone asks the following question “We added our application port to the services file and now some other application is using it – why”. The answer is because the services file does not reserve port numbers. The services file exists so that applications can call the getservbyname function to find the port number associated with a service or call the getservbyport function to find the name of a service associated with a port number. There is nothing to prevent two different services from mapping to the same port number, although the getservbyport function will return only the first one. There is also no requirement that an application call getservbyname to find out what port it should be using. An application developer can just hard code a port number or allow it to be entered as a parameter.

There is no way to reserve a port number – other than to use it, and then only if you do not set the REUSEADDR socket option; so start you application as soon as possible after STCP is started, before that other application grabs your port.

 

Sometimes the culprit is not another server application but a client application. Most client applications do not bind to a specific local port, but since a local port is needed STCP assigns one from the dynamic port range (49152 – 65535). If your application uses a port in this range I suggest that you change it to use a port from the registered range, 1024-49151. These ports will only be used if an application explicitly binds to them.

 

OK, let’s assume that there is another application out there using your application’s port; how can you identify what application it is and more importantly who started it? It is a three step process:

 

  1. Run the command “netstat -numeric -all_sockets -PCB_addr” and identify the interloper, in this case the port number I am interested in is 13592.
netstat -numeric -all_sockets -PCB_addr
Active connections (including servers)
PCB       Proto Recv-Q Send-Q Local Address Foreign Address
(state)
. . .
8e3aa300 tcp        0      0 *:13592          *:*          LISTEN
. . .
ready 13:50:12
  1. Run the command

“analyze_system -request_line 'match dv; dump_onetcb 8e3aa300' -quit”

passing to the dump_onetcb request the PCB of the interloper, 8e3aa300. This identifies the STCP device associated with the socket.
OpenVOS Release 17.0.1aj, analyze_system Release 17.0.1aj
Current process is 664, ptep 8E0EE800, Noah_Davids.CAC
sth_dvtx                 = 121 (stcp.m16_202)
  1. Run the command “who_locked #stcp.m16_202” to determine what process is using the device.
stcp.m16_202:
Object is write locked by Barney_Rubble.Dev (login) on module
%vs#m1
executing stcp_calls.pm.

 

And there you have it, all you need to do now is contact this Barney Rubble and politely suggest that he use a different port number.