Intermittent Execution Glitches (non-fatal malfunctions) in Server Environment

[David_Caruthers]

Intermittent bypassing(non-execution) of blocks of code when running in a server environment. Other intermittent server environment only errors.

I have a problem that a single-threaded large console application will intermittently fail to execute certain blocks of code.

Another similar problem is that again intermittently string comparisons in a certain block of the code will fail when the executable is made part of a service.

These failures cause runs with identical input to generate differing output. Again this is only when used as a service. The same executable when run from the Windows command prompt produces totally repeatable results.

Is there a catch for this or are there special precautions to take when running a console type executable as the core of a service. My area of the project with this code is to maintain the FORTRAN executables, while others handle the server and .net environments.

The code involved produces an approximately 8MB executable and use several internal scratch files. The code is legacy VMS FORTRAN 77 that has been updated to run under Visual FORTRAN XE.

Skipped blocks of executable appear as totally missing execution if IF-THEN-ELSE blocks with the entire source area from IF to ENDIF being ignored (both THEN and ELSE blocks).

Help!

[Steven_L_Intel1]

I can't think of anything special you need to do here to run Fortran code as a Windows service. The symptoms you describe suggest that you have references to uninitialized variables - this is especially likely if you ported from VMS where the default was that all local variables have the implicit SAVE attribute.

[David_Caruthers]

Quoting David Caruthers

Intermittent bypassing(non-execution) of blocks of code when running in a server environment. Other intermittent server environment only errors.

I have a problem that a single-threaded large console application will intermittently fail to execute certain blocks of code.

Another similar problem is that again intermittently string comparisons in a certain block of the code will fail when the executable is made part of a service.

These failures cause runs with identical input to generate differing output. Again this is only when used as a service. The same executable when run from the Windows command prompt produces totally repeatable results.

Is there a catch for this or are there special precautions to take when running a console type executable as the core of a service. My area of the project with this code is to maintain the FORTRAN executables, while others handle the server and .net environments.

The code involved produces an approximately 8MB executable and use several internal scratch files. The code is legacy VMS FORTRAN 77 that has been updated to run under Visual FORTRAN XE.

Skipped blocks of executable appear as totally missing execution if IF-THEN-ELSE blocks with the entire source area from IF to ENDIF being ignored (both THEN and ELSE blocks).

Help!

As a follow up to this. I have eliminated the worst offenses of this intermittent problem by rebuilding the executable as Release rather than Debug. This eliminated all but one of the areas where intermittent execution occured.

It seems the Microsoft Server environments don't like to reliably execute Visual FORTRAN progams that have been build in debug mode.

I am still eliminating all the unused and undeclared (declared by the use of implicit which was a company standard at the time the code was originally generated) variables from all the source to see if that will improve reliability. My the server environment is picky.

Thanks for the help so far.

[Steven_L_Intel1]

In the end you will find that the problems have nothing to do with the language being Fortran nor being debug builds, though the latter introduces other issues that could cause problems in some cases. Not intermittent problems, though.

[mecej4]

> My the server environment is picky.

That is uncalled for.

I routinely test programs on different hardware and operating systems, using different compilers. A big program in which bugs have gone uncaught for a long time can exhibit perplexing behavior on one platform, and run perfectly normally on another. It does not follow that the former is a "picky" platform. Another run, with different input data, can result in a bad run on the second platform. Such bugs can be quite difficult to track down and fix, but that is the price to be paid for not anticipating and removing the bugs earlier.

In fact, this unpredictability is a good sign that there are bugs in the program. Attributing that behavior to the OS being picky is wrong.

Common errors: mismatched or missing subprogram arguments; assuming that local variables are saved; assuming that integer and real variables are automatically initialized to zero; assuming that array overruns are harmless if there is plenty of RAM on the machine, and so on.

[David_Caruthers]

The largest problem is that the code was written well but was written to Digital Equipment Corporation FORTRAN and VMS Alpha specifications, enhancements, run-times, and utillities. With the VMS operating system and DEC FORTRAN being matched to each other this makes what was acceptable and common practice with that system a large problem for porting.

I am still chasing those problems. With the blessing of DEC many of the routines involved were written to accept 1 byte "logicals" as signed byte integers and also use the least significant byte of 2 and 4 byte integers passed as parameters.

There one main reason for migrating the product to the Windows domain and that is cost, and availability of people to maintain the VMS systems.

The interesting phenomenon is that given the same data, exactly the same data, the same executable will produce different results on successive runs, This has not happened when running the executable under XP, Windows 7 (32 bit) and Windows 7 (64 bit), but only occurs when running under Windows Server after it has been encapsulated as a service.

[mecej4]

Did you read the recommendations given under the link Migrating from CVF ? In particular, Compaq/Digital Fortran treated local variables to have the attribute SAVE, but Intel Fortran does not. Intel Fortran does provide a /Qsave option to support the implicit SAVE behavior, but it is not a default and must be specified explicitly.

If you have not tried /Qsave, please consider doing so, and recompile and link all sources after specifying this option.