Failing socket reads - same software...

[Willem Grooters]

Environment: One machine, VMS 7.1-2, TCPIP 5.0A ECO1. It concerns a production system, not clustered (for what we know) and remote, from my point of work.

A TCPIP service has been defined on ports 2003 and 2004, each accessed by one application running on two other, clustered VMS boxes in the network. The services run under two different users that are equal in all terms except name and UIC member. The commandprocedures are equal except for the naming of some outputfiles, executed programs and data are the same.

We found that one service has no problem at all and runs flawlessly, the other fails to read the socket properly and therefore it receives the wrong data and may encounter fatal conditions causing the read to abort (and the program to crash).

To avoid a problem that _may_ occur by a different setting on the sendig application, we tried to mimic these requests (we know exaclty what is sent) we used TELNET from the system itself to the failing port. But the results show that the first byte(s) of the message are lost.

We did disable the service and enabled it again but that did not make any difference.

Also, we tried to figure out what is sent and received by the failing port. We found that a lot of RCV packets are received, where no activity is know to access this port at that time. The counters on the BG-device conected to this service however shows 1 receipt, but no bytes read, no writes at all.

Data cannot be shown at the moment, but can be reproduced at will.

We ran out of ideas what could cause the problem. Any ideas where we can look more?

[Antoniov.]

Willem,
I don't know if your service uses TCP o UDP socket. UDP doesn't grant receiving and you cannot use same port for two different applications.

Antonio Vigliotti

[Willem Grooters]

Further investigations this morning, with access to all systems involved, unearthed a misconfiguration of application parameters. Our perception of the problem was based on information the system manager was sure to be true and complete. Well, it proved to be incomlete and simply straight wrong.
Not just the person to blame, since a change in application environment that was hidden to us, could not be handled by the software alone; Something, the system manager and any person would expect. The program that should have reacted coreectly will be adjusted - and documentation improved.