时不时有人会问以下问题："我们把我们的应用程序端口添加到服务文件中，现在有其他应用程序在使用它--为什么"。答案是，因为服务文件不保留端口号。服务文件的存在是为了让应用程序可以调用 getservbyname 函数来查找与服务相关联的端口号， 或者调用 getservbyport 函数来查找与端口号相关联的服务名称。没有什么可以阻止两个不同的服务映射到同一个端口号，尽管getervbyport函数只会返回第一个。也没有要求应用程序必须调用 getservbyname 来找出它应该使用的端口。应用程序开发人员可以直接对端口号进行硬编码， 或允许将其作为参数输入。
没有办法保留端口号--除了使用它，而且只有在不设置REUSEADDR套接字选项的情况下才能使用；所以在STCP启动后，在其他应用程序抢占你的端口之前，尽快启动你的应用程序。
有时，罪魁祸首不是另一个服务器应用程序，而是一个客户端应用程序。大多数客户端应用程序并不绑定到特定的本地端口，但是由于需要本地端口，STCP会从动态端口范围（49152 - 65535）中分配一个端口。如果你的应用程序使用这个范围内的端口，我建议你把它改为使用注册范围内的端口，1024-49151。这些端口只有在应用程序明确绑定到它们时才会被使用。
好吧，让我们假设有另一个应用程序在使用您的应用程序的 port；如何识别它是什么应用程序，更重要的是谁启动了它？这是一个三步走的过程。
- 运行以下命令
“netstat -numeric -all_sockets -PCB_addr”并识别干扰者，在这种情况下，我感兴趣的端口号是13592。
netstat -numeric -all_sockets -PCB_addrActive connections (including servers)PCB Proto Recv-Q Send-Q Local Address Foreign Address(state). . . 8e3aa300 tcp 0 0 *:13592 *:* LISTEN. . .ready 13:50:12- 运行以下命令
“analyze_system -request_line 'match dv; dump_onetcb 8e3aa300' -quit”
传递给dump_onetcb请求的interloper的PCB，8e3aa300。这标识了与插座相关联的STCP设备。
OpenVOS Release 17.0.1aj, analyze_system Release 17.0.1ajCurrent process is 664, ptep 8E0EE800, Noah_Davids.CAC sth_dvtx = 121 (stcp.m16_202)- 运行以下命令
“who_locked #stcp.m16_202”以确定使用该设备的是什么流程。
stcp.m16_202: Object is write locked by Barney_Rubble.Dev (login) on module%vs#m1 executing stcp_calls.pm.
你现在要做的就是联系这个Barney Rubble 礼貌地建议他使用不同的端口号。