That the code didn't overtly fail on Alpha does not imply that there are no latent bugs; that the code is bug-free.
There have been latent bugs for decades in some commonly-used code, too.
I've found some of my own after a decade or more of use of the code.
As for your questions around the applicability of the qualifiers, various programmers will turn off the optimizer because they encountered odd run-time errors with the code. If that compilation switch change then masked the error, then some programmers will choose to leave it; to not to research what is often a latent error in the code, and the code will remain unoptimized. (These can be somewhat nasty to find, too; stack-smashing, buffer overflows, IOSBs or variables that are used asynchronously and particularly after the stack frame leaves scope, etc.)
Various programmers also use /STANDARD=VAXC because the compiler-generated diagnostics were viewed as noise. Some will use it because some module actually contains K&R constructs or VAX C extensions, and because they (for whatever reason) didn't remove those constructs.
Together, the use of /NOOPTMIZE and /STANDARD=VAXC imply that this might be poor-quality and/or older C code. Most of the VAX C code (K&R-era code, rather than the ANSI C compiler for VAX) was pretty wonky.
Put another way, few folks will choose to use those qualifiers for any reason other than masking errors and diagnostics; errors that the compiler found, and that the programmer decided were spurious and/or too much work to address. Some of the diagnostics generated in these older code-bases will be spurious. Some will be pedantic. Some will be latent bugs.
I've seen more than a few of these cases over the years that tracked back to (for instance) dropped a quadword 1 into the stack of a now- inactive stack frame, and nothing in the code ever noticed that. Well, not until after a VMS upgrade, or a faster VAX processor or an SMP box was deployed, or after an Alpha or Itanium port.
>it seems to me to be reasonable to strongly suspect that the problem is due to differences in the Alpha/Itanium
architecture...
My preferred rule of thumb for these sorts of run-time errors: if the error is cropping up within my code, then it's my bug, at least until I prove it's not my bug. Usually starting with higher-than-typical diagnostics. Once I've proved that the trigger is not my bug, then I usually have some sort of a reproducer, and I can hand that reproducer off to whomever is supporting the errant code (which can also makes for faster turn-around for a fix, too) , and I can later use that reproducer to verify the fix when it arrives.
And if I find that the bug in my code, well, I've found the bug.
Assuming that these sorts of run-time errors are caused by somebody else's bug - as a starting point for the debugging and the related discussion - usually only delays the resolution.
To harden a production application, adding process dumps to normal operations is typical, as is adding signal handlers into code, and adding integrated debugging. All typical. Increasing the reliability of existing code and getting to where it can be more easily debugged is an ugly, slow and nasty slog - particularly in large and gnarly and old C code code-bases - but that's how applications are made more reliable, and how you can catch and debug and resolve errors with fewer failures.
