That's a generic RPC error. Off the top, look for dangling network connections, and for errors that would prevent a connection.
You went from a functional release to a new architecture and a release and a new compiler, and on a version that's had issues in other areas. Instruction timings and performance characteristics change. Stack contents change. In aggregate, that's a significant change.
First stop is loading the current relevant patches. Then call the HP support center, asking for anything relevant that hasn't been released as a patch that's related to networking or RPC or TCP/IP Services. (There have been various issues with VMS and TCP, and your own code is always going to be a big suspect.)
If the patches are not successful and if HP Support doesn't know of any relevant details or fixes or errors, then you're going to have to locate which resource is being depleted; a channel leak looks like a potential candidate. You're going to be debugging this.
That this application worked before is not as relevent as any of us might hope. There can be latent bugs exposed by a port, and there can be latent bugs lurking in otherwise working code for decades.
When approaching this, consider your source code to be buggy, and work to prove that it's not. Once you've proved your code is not the trigger, then you now have fodder to work with HP support to resolve the error. Or if not, you've found your bug.
When you've got the wedge, crash the process (writing out a process dump) and have a look at the carcass. That might involve building with debugging information. But you've found a good reproducer, so you've got a path to resolve this. Watching the network traffic is one tactic here, but I'd look at the source code, too; if this is a channel leak (for instance), that might or might not show up in a packet trace.
