Subject: Migration to Intel Visual Fortran
Name: D. Robinson
Date: December 4, 2007
Variants affected: ALL

Description:

I've just completed an update of our FVS build/debug tools, moving from
MS Developer Studio 2008 with Compaq Visual Fortran, to the Dev Studio
2005 .Net with Intel Visual Fortran. 

I've figured out how to build and configure the mixed language code with
the legacy 3rd party DBS software, and have tested outputs from the previous
and the new builds. They are identical with the exception of some last-digit
differences in new regen. I attribute this to rounding differences.

In the course of doing the update, I encountered some compiler complaints
that could not be silenced! I made the necessary changes to get these to
compile and propose that they be merged into the FVS code base, since they
help keep the code base in line with modern standards.

There are 15 routines in total: five for Nick to approve described below,
and ten for Lance to be released soon.

Impact on users: None

Files:
 1. fvs/base/src/exppe.for
 2. fvs/base/src/opadd.for
 3. fvs/dbs/src/dbsexecsql.for
 4. fvs/dbs/src/dbsopen.for
 5. fvs/fire/fofem/src/fm_fofem.c

================================================
For Nick:
================================================

base/src/exppe.for
- Entry point PPEVMI expects to have arrays as its 2nd and 3rd arguments.
  The new syntax is explicit.

base/src/opadd.for
- Call to OPCYCL expects to have an array as the 2nd argument. The new
  syntax is explicit.

dbs/src/dbsexecsql.for
- Call to ALGKEY expects to have a 4-byte integer as its final argument;
  IRET is 2-byte. This is not a very strong update. It would be better to
  have a true 4 byte argument in the first place.

dbs/src/dbsopen.for
- Call to f90SQLGetInfo expects to have a non-zero value for the length of
  the preceding character argument (DBMS). Severe stack errors otherwise!

fire/fofem/src/fm_fofem.c
- Internal function "Put_CISI (d_CI *a_CI, d_SI *a_SI)" must return an int.
  The new syntax is explicit. There is no way to make the MS C++ compiler
  ignore this!

================================================
Don Robinson
ESSA Technologies
drobinson@essa.com
604.535.1997
================================================

