Customer called in with a SQL3008N error and stated they could not connect to DB2 with Petroware.
Found using command "netstat -ano" that DFSR was using port 50000.
Change the services file to change the DB2 port to 50001.
Edited the configs on the PCs to reflect the new port.
PC's were able to connect after changes were made and applied.
Customer IT responded:
The DFSR service was indeed using network port 50000 as Petroware support described. I’ve applied a fix to prevent this from happening again, long-winded explanation of what happened and the fix below. I would not reverse anything that was done earlier this morning unless Petroware support recommends it.
DFSR is a built-in Windows program on a server, and like a handful of other services in Windows it grabs a number of network ports that it can “listen” on at random from available free ports. If something else is occupying a port, it just selects another. (A port, by the way, is an additional specifier value in IP networking to clarify who or what you’re talking to; if an IP address was a building address, the port would be a more specific suite or office # inside the building).
Petroware’s database always wants its one particular port, which before this morning was port 50000. For whatever reason, this other service, luck-of-the-draw, got in and claimed the 50000 port before DB2 could, shutting DB2 out so that no one could connect to it. Petroware support changed DB2’s configuration to use port 50001, which got you functional this morning. However, next time the server restarts, or a year from now, there could still be the chance that DFSR luck-of-the-draw chooses port 50001 and there’s an outage again.
Looking further, I found that DFSR can be “taught” to use one particular network port, and I’ve done that now, telling it to always use port 49999, which nothing else was using, and restarted the service twice and confirmed it chose port 49999 each time.