I have an application written in C language using socket routines to communicate with a machine. This application has been running for years with no problem detected.
Last week our IT team put another network card in VMS machine and the communication became too instable, sometimes works, sometimes doesn't.
Yeah, you need to do some debugging and figure out if this is the network card, a network issue, a duplex or speed setting or negotiation issue, an IT-induced problem, a VMS bug or (best guess) your code is buggy.
That you're here implies that latent errors often implies that the application code is the likely culprit.
You'll next and justifiably point out that the code has run flawlessly for [insert years], which is typical of the story arc of previous posters with buggy code.
We'll then ask for a reproducer of the issue, and you'll eventually be convinced that's necessary, but will have some difficulty creating that reproducer, as it's probably something in the existing application code; the standalone reproducers will tend to work.
Which then leads to a discussion of asynchronous synchronization techniques, proper IOSB handling and allocations, and various related issues.
If the story arc here ends where it often does, the C code is found to have one or more latent errors in a central I/O path, and which have been exacerbated by performance differences with the controller.
For the occasional variation to maintain interest in the usual "it broke! why?" story arc here, sometimes we'll work through this with you to discover that there's a bad or loose cable, or a faulty controller, or a switch is set incorrectly or has mis-negotiated its speed setting or its duplex setting, an IP or VMS software bug that's come to the fore, or the switch port has gone weird as managed switches are occasionally wont to do.
