30 Miles of Bad Code (FORTRAN->C)

We have been blessed with a large S/W dump from a vendor.
The s/w is really old crufty FORTRAN which isn't supported
in our operational environment ( Winders Ecks-Pee + a proprietary
component based real-time architecture ).
The vendor is not required to do anything under the terms of their
contract, sigh...

Looks like we'll have to convert the code to C at least.

We've tried "f2c" and some store-bought packages but they all
have issues with the code in question ( did I mention it was ugly,
even by spaghetti code standards ). If this was just a one
shot thing we might go through and manually fix the several hundred
problems before converting but this is liable to be a recurring issue.

Any ideas on what we might do to mitigate the recurrent effort.
Tools?
Nuking the vendor in question?

My first instinct would be to bite the bullet and go through the
code fixing and documenting fixes for the hundreds of errors we
see. Some of the rrros are likely to be consequences of a single
oops but an initial analysis looks like most of the crud is distinct
in nature.

TIA

<ibm@svpal.org> wrote in message
news:1115303630.835480.122710@g14g2000cwa.googlegroups.com...
> We have been blessed with a large S/W dump from a vendor.
> The s/w is really old crufty FORTRAN which isn't supported
> in our operational environment ( Winders Ecks-Pee + a proprietary
> component based real-time architecture ).
> The vendor is not required to do anything under the terms of their
> contract, sigh...
>
> Looks like we'll have to convert the code to C at least.
>
> We've tried "f2c" and some store-bought packages but they all
> have issues with the code in question ( did I mention it was ugly,
> even by spaghetti code standards ). If this was just a one
> shot thing we might go through and manually fix the several hundred
> problems before converting but this is liable to be a recurring issue.
>
> Any ideas on what we might do to mitigate the recurrent effort.
> Tools?
> Nuking the vendor in question?
>
> My first instinct would be to bite the bullet and go through the
> code fixing and documenting fixes for the hundreds of errors we
> see. Some of the rrros are likely to be consequences of a single
> oops but an initial analysis looks like most of the crud is distinct
> in nature.

Even if you intend to convert to C, you most likely will expedite your
project by getting it minimally working in Fortran first.  Nearly all
Fortran compilers support everything f2c will accept, plus more extensions
than anyone here would approve.  If the first few errors stump you, you are
welcome to post them here.

Certainly, if you must continue to pay the vendor, you should ask for a
cleanup.

ibm@svpal.org wrote:

> We have been blessed with a large S/W dump from a vendor.
> The s/w is really old crufty FORTRAN which isn't supported
> in our operational environment ( Winders Ecks-Pee + a proprietary
> component based real-time architecture ).
> The vendor is not required to do anything under the terms of their
> contract, sigh...

One might wonder which "genius" signed that "contract" (as I understand the
term, both parties are usually supposed to either do something and / or
desist from doing something else). A caveat emptor kind of sale does not
jibe well with the definition of a contract agreed to between two sane
parties.

>
> Looks like we'll have to convert the code to C at least.
>
> We've tried "f2c" and some store-bought packages but they all
> have issues with the code in question ( did I mention it was ugly,
> even by spaghetti code standards ). If this was just a one
> shot thing we might go through and manually fix the several hundred
> problems before converting but this is liable to be a recurring issue.

I really sympathise with your situation. A problematic OS + negligent vendor
and now poorly written code.

>
> Any ideas on what we might do to mitigate the recurrent effort.
> Tools?
> Nuking the vendor in question?

That would be a start. Followed perhaps (depending on your requirements) by
shifting to a more friendly and dependable OS (Linux / BSD come to mind)
which have all the tools you need, obviating the need to mess around with
cygwin, or tweaking a toy OS to do serious work. Imagine having done all
this work and then one of windoze' blessings (aka viruses, etc.) comes
calling. One of my former coworkers once lost his Master's thesis (written
in Word) to a virus, 3 days before it was due. Not an experience any
reasonable person should have to go through. I would suggest the above, no
matter whether you were working with C or fortran.

And also hiring a fortran programmer (in case you are disinclined to do the
task yourself - I have worked with old undocumented code written by someone
else, so I know what the experience is like - not something I would care to
repeat) to translate the code into non-prehistoric fortran (maybe fortran
95).

Are the errors you see in trying to compile the fortran or when trying
to compile the C after conversion?

Getting it working in fortran would be a good start. Then there are
several code beautifiers/modernizers/spaghetti code restructurers
around. One that I have used is plusfort (spag). From their manual:

2.1.1 What does it do?
SPAG is a multi-purpose tool for analyzing and improving Fortran
programs. It combines restructuring and re-formatting with translation
to Fortran 95, and both static and dynamic analysis in a single powerful
package. But SPAG offers facilities which go beyond the sum of these
parts. For example:
* SPAG can restructure 'rats-nest' Fortran 66 to modern and
structured Fortran (77 or 95), or apply a final polish to well written
modern code. Progress can be monitored using 'Before and After'
complexity metrics.
etc...

After getting better f95, you can then attack the conversion problem.



ibm@svpal.org wrote:
> We have been blessed with a large S/W dump from a vendor.
> The s/w is really old crufty FORTRAN which isn't supported
> in our operational environment ( Winders Ecks-Pee + a proprietary
> component based real-time architecture ).
> The vendor is not required to do anything under the terms of their
> contract, sigh...
>
> Looks like we'll have to convert the code to C at least.
>
> We've tried "f2c" and some store-bought packages but they all
> have issues with the code in question ( did I mention it was ugly,
> even by spaghetti code standards ). If this was just a one
> shot thing we might go through and manually fix the several hundred
> problems before converting but this is liable to be a recurring issue.
>
> Any ideas on what we might do to mitigate the recurrent effort.
> Tools?
> Nuking the vendor in question?
>
> My first instinct would be to bite the bullet and go through the
> code fixing and documenting fixes for the hundreds of errors we
> see. Some of the rrros are likely to be consequences of a single
> oops but an initial analysis looks like most of the crud is distinct
> in nature.
>
> TIA
>

<ibm@svpal.org> wrote in message
news:1115303630.835480.122710@g14g2000cwa.googlegroups.com...
> We have been blessed with a large S/W dump from a vendor.
> The s/w is really old crufty FORTRAN which isn't supported
> in our operational environment ( Winders Ecks-Pee + a proprietary
> component based real-time architecture ).
> The vendor is not required to do anything under the terms of their
> contract, sigh...
>
> Looks like we'll have to convert the code to C at least.
>
> We've tried "f2c" and some store-bought packages but they all
> have issues with the code in question ( did I mention it was ugly,
> even by spaghetti code standards ). If this was just a one
> shot thing we might go through and manually fix the several hundred
> problems before converting but this is liable to be a recurring issue.
>
> Any ideas on what we might do to mitigate the recurrent effort.
> Tools?
> Nuking the vendor in question?
>
> My first instinct would be to bite the bullet and go through the
> code fixing and documenting fixes for the hundreds of errors we
> see. Some of the rrros are likely to be consequences of a single
> oops but an initial analysis looks like most of the crud is distinct
> in nature.
>
> TIA
>

You don't say what in the code is causing the problems. However, many
Fortran compilers can accommodate such old code - with Visual Fortran there
is an option to switch on Fortran 66 interpretation of DO loops and. more
importantly, extended-DO loops. I had code that would jump out of a DO loop
to an error handler, then jump back again. Something like (forgive me if I
get the syntax slightly wrong - this is not my natural way of error
handling!)

DO 10, I = 1, 100
READ(10, *, ERR = 600) (X(J,I), J = 1, 10)
10 CONTINUE
...

600 PRINT *, 'Error reading line', I
GOTO 10

....

In the event, I rewrote the relevant lines to not need extended DO

DO 10, I = 1, 100
READ(10, *, ERR = 600) (X(J,I), I = 1, 10)
GOTO 10
600 PRINT *, 'Error reading line', I
10 CONTINUE

Tedious. But gets rid of the main FORTRAN 66 impediment to compiling the
code. All the FORTRAN 66 code I have ever worked with has assumed (1) That
DO loops will have at least one pass, and (2) that that is now what is
wanted, so they explicitly code a check that is now implicit with FORTRAN 77
and later. To relieve the boredom of the extended DO loop stuff I would
remove the checks if it was close by the code I was cleaning up.

As another poster has noted, there are tools that will automate this for
you, and SPAG sounds good. What would be nice, and SPAG used not to do this,
would be something that also identifies where array syntax can be used -
this I find a great help in cleaning up code.

I'd also go along with another poster - if you can't satisfy yourself with a
clean Fortran compile, what confidence would you have that the C translation
was valid?

J DUDLEY wrote:

> As another poster has noted, there are tools that will automate this
for
> you, and SPAG sounds good. What would be nice, and SPAG used not to
do this,
> would be something that also identifies where array syntax can be
used -
> this I find a great help in cleaning up code.

I am interesed in this too, but the only tool I know of, VAST/77to90
http://www.crescentbaysoftware.com/vast_77to90.html , costs $16,000 for
unlimited use. Googling "vast 77 90" in this ng brings up a detailed
review by John Prentice posted in 1993.

I wonder how hard it would be to write a tool that does some
vectorizations. Just replacing the ubiquitious F77 construct

xsum = 0.0
do i=1,n
xsum = xsum + x(i)
end do

with

xsum = sum(x)

would be of some of value.

ibm@svpal.org wrote:
> We have been blessed with a large S/W dump from a vendor.
> The s/w is really old crufty FORTRAN which isn't supported
> in our operational environment ( Winders Ecks-Pee + a proprietary
> component based real-time architecture ).
> The vendor is not required to do anything under the terms of their
> contract, sigh...

How about running it under an emulator for whatever it used to run on.
At least then you could start with working code. Yes there is even IBM
360/370 emulation out there running old MVS, or maybe this came from an
IBM-1130.

> Looks like we'll have to convert the code to C at least.

I think it is time to a corollary to Brooks' law:

Switching from Fortran to C makes a late software project even later.

"ibm@svpal.org" wrote:
>
> Any ideas on what we might do to mitigate the recurrent effort.
> Tools?
> Nuking the vendor in question?

No, *hire* their contract lawyer and *fire* yours!
As for tools, check

http://cobalt-blue.com

They've been around awhile, they're reasonably priced and have Fortran
structuring tools and Fortran to ANSI C translator.

> I wonder how hard it would be to write a tool that does some
> vectorizations. Just replacing the ubiquitious F77 construct
>
> xsum = 0.0
> do i=1,n
>    xsum = xsum + x(i)
> end do
>
> with
>
> xsum = sum(x)
>
> would be of some of value.

For many compilers I've seen, this produces code that performes exactly the
same.

Jan

Jan Vorbr=FCggen wrote: 
>
> For many compilers I've seen, this produces code that performes
exactly the
> same.
>
> 	Jan

I also have observed that. I want a source-to-source vectorizer that
makes a code shorter, not necessarily faster.