Maintaining a Dusty Deck

Hi Fortraners,

I've been maintaining an old code, ~500 subroutines and
~90000 lines and have run into a problem.

I'm using CVF V6.6(b?) and the MS IDE.

When the subroutines are arranged 1 subroutine per file,
the program compiles, links, and runs okay.

I'd like to organize the code into modules.

As a first step, I have written some fortran source files using only
"include" statements with the names of the subroutines intended to be used
in the modules.

Just to be clear, I'm not using modules yet.

Compiling this source generates countless errors.

I mean countless.

Any change seems to trigger a cascade of different errors.

If the code generates reasonable output for the test cases,
am I fooling myself by thinking the code has some integrity.

I find it suprising that the way the code is presented to the compiler
would matter like this.

My dilemna is: should I leave the code as is (1 sub/file), or force the
organization.

Thanks, all comment appreciated.

Rob

"rih5342" <rob.hickey@nospam.alum.mit.edu> writes:

> As a first step, I have written some fortran source files using only
> "include" statements with the names of the subroutines intended to be used
> in the modules.

I don't quite understand that.  One includes files - not subroutines.
I think showing an actual sample woudl work better than trying to
explain it in words, even if it were an incomplete sample.

> Compiling this source generates countless errors.
>
> I mean countless.

Well, how about showing us at least one of them?

I think we need some specifics here.  Show us Fortran instead of
English.  I just don't see any hard data to work with.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

rih5342 wrote:
> Hi Fortraners,
>
> I've been maintaining an old code, ~500 subroutines and
> ~90000 lines and have run into a problem.
>
> I'm using CVF V6.6(b?) and the MS IDE.
>
> When the subroutines are arranged 1 subroutine per file,
> the program compiles, links, and runs okay.
>
> I'd like to organize the code into modules.
>
> As a first step, I have written some fortran source files using only
> "include" statements with the names of the subroutines intended to be used
> in the modules.
>
> Just to be clear, I'm not using modules yet.
>
> Compiling this source generates countless errors.
>
> I mean countless.
>
> Any change seems to trigger a cascade of different errors.
>
> If the code generates reasonable output for the test cases,
> am I fooling myself by thinking the code has some integrity.
>
> I find it suprising that the way the code is presented to the compiler
> would matter like this.
>
> My dilemna is: should I leave the code as is (1 sub/file), or force the
> organization.
>
> Thanks, all comment appreciated.
>
> Rob
>

As a first step you can try to get many of the benefits of F90 for
little effort. A scheme that worked for me was to change the main
program into subroutine main and include everything after a "contains".
So

program NEW
implicit none
call main
contains
include "first file"
..
include "last file"
end

and fix bugs. The gotchas are that external statements "hide" the
functions so passed subroutine names will not work. This will
clean out bad calls (amazing how many are still there!) and
allow a start on use of assumed shape (":") rather than assumed size
("*"). One of the effects of modules is to have explicit interfaces
built for you. This also gets those interfaces built for you.
A module of interface blocks is a recipe for trouble and not
suggested by or for anyone (other than for some library builders under
other sorts of duress!).

"rih5342" <rob.hickey@nospam.alum.mit.edu> wrote in message
 news:b952c0555b0dfa9ed41893ce18724b97@lo
calhost.talkaboutprogramming.com...
>
> Hi Fortraners,
>
> I've been maintaining an old code, ~500 subroutines and
> ~90000 lines and have run into a problem.
>
> I'm using CVF V6.6(b?) and the MS IDE.
>
> When the subroutines are arranged 1 subroutine per file,
> the program compiles, links, and runs okay.
>
> I'd like to organize the code into modules.
>
> As a first step, I have written some fortran source files using only
> "include" statements with the names of the subroutines intended to be used
> in the modules.
>
> Just to be clear, I'm not using modules yet.
>
> Compiling this source generates countless errors.
>
CVF performs call interface checking by default when everything is compiled
together.  With separate compilation, you would get checking only at run
time, only if you asked for it.  If you use modules, you will force the
compiler to perform some of these checks.  When checking, CVF does reject
some things which are dangerous but wouldn't necessarily cause failure.

rih5342 wrote:
>
> My dilemna is: should I leave the code as is (1 sub/file), or force the
> organization.

Forget about modules and set your mind on dlls - a headache free
transition that will keep your dusty deck speeding along, while the
"misguided" would still be poking around their silly interfaces.

bv <bvoh@Xsdynamix.com> wrote:
>rih5342 wrote: 
>
>Forget about modules and set your mind on dlls - a headache free
>transition that will keep your dusty deck speeding along, while the
>"misguided" would still be poking around their silly interfaces.
>

Quoting Catherine Rees Lay from a recent message here with subject "Re: Prob
lem
with double precision function":

"Whether or not he uses a DLL has absolutely nothing to do with whether
he should use a module.

DLLs are OS-specific file types, and whether you get one or not depends
on how you link your object files, module files, lib files etc.

Modules, on the other hand, are a type of source code, and can be built
into libraries, DLLs, executables and I've no doubt a wide variety of
other system-dependent things.

I like DLLs for a lot of situations. Generally mine have modules in
them."



----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==--
--
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 News
groups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =
---

"rih5342" <rob.hickey@nospam.alum.mit.edu> wrote:
>
>Hi Fortraners,
>
>I've been maintaining an old code, ~500 subroutines and
>~90000 lines and have run into a problem.
>
>I'm using CVF V6.6(b?) and the MS IDE.
>
>When the subroutines are arranged 1 subroutine per file,
>the program compiles, links, and runs okay.
>
>I'd like to organize the code into modules.
>
>As a first step, I have written some fortran source files using only
>"include" statements with the names of the subroutines intended to be used
>in the modules.
>
>Just to be clear, I'm not using modules yet.
>
>Compiling this source generates countless errors.
>
>I mean countless.
>
>Any change seems to trigger a cascade of different errors.
>
>If the code generates reasonable output for the test cases,
>am I fooling myself by thinking the code has some integrity.
>
>I find it suprising that the way the code is presented to the compiler
>would matter like this.
>
>My dilemna is: should I leave the code as is (1 sub/file), or force the
>organization.
>
>Thanks, all comment appreciated.
>
>Rob

Programming in F77 without MODULEs or INTERFACEs, if you compile each source
file into an object file and then link the object files to create an executa
ble,
the compiler may not catch certain errors, in particular procedures called
with the wrong number or type of arguments. When compiling the entire progra
m
at once, in your case using INCLUDE, the compiler may catch those errors.
How much checking is done depends on the compiler. Do the compiler error
messages point to real problems in your code?

I suggest trying the free Fortran 77 static analysis tool FTNCHEK.



----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==--
--
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 News
groups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =
---

Gordon Sande wrote:

> rih5342 wrote:
> 

[...]

> As a first step you can try to get many of the benefits of F90 for
> little effort. A scheme that worked for me was to change the main
> program into subroutine main and include everything after a "contains".
> So
>
>  program NEW
>    implicit none
>    call main
>    contains
>  include "first file"
>  ...
>  include "last file"
>  end
>
> and fix bugs. The gotchas are that external statements "hide" the
> functions so passed subroutine names will not work. This will
> clean out bad calls (amazing how many are still there!) and
> allow a start on use of assumed shape (":") rather than assumed size
> ("*"). One of the effects of modules is to have explicit interfaces
> built for you. This also gets those interfaces built for you.

On the other hand, this approach runs a significant risk of introducing
new bugs because of subroutines acquiring variables by host association.
That risk would be reduced or eliminated if one could be certain that
each subprogram declared all the variables it uses, but in my experience
that is not the case in a typical dusty deck.  If a subroutine and the
main program happen to use different variables with the same name, and
if the subroutine's is not declared, then the program semantics are
different when the subroutine is contained in the main program than when
it is external.

My first step in these cases is usually to try to clean up the code and
bring it into conformance with Fortran 77.  FTNCHEK is my workhorse
here.  In light of my comments above, one of the things FTNCHEK can do
is to generate declarations for undeclared variables, which can be a big
time saver.  But it can do much, much more.


John Bollinger
jobollin@indiana.edu

>My dilemna is: should I leave the code as is (1 sub/file), or force the
>organization.

Neither -- as others have suggested, there are many possible intermediate
steps that you can and should try first.

1) present organization - make sure all variables are declared
2) start regrouping in a small way, find, understand and fix all
problems found
3) code checkers are helpful
4) compiling with alternate compilers can also be helpful (OpenWatcom,
G77 & possilbe the "free, personal" versions of various F77 compilers)

Do not attempt to get everything in one file as the first step, it
is too much at once.

Once strict F77 conformance is achieved and confirmed, rewriting
interfaces to F95 module style can be started (if you want).

> On the other hand, this approach runs a significant risk of introducing
> new bugs because of subroutines acquiring variables by host association.

I di not think this can happen here - the program is empty except for the
CALL MAIN. Subroutines on the same level of containment, as it were, do not
share variables.

Jan