🚀 go-pugleaf

In article <1k6e6cINNmqo@bigboote.WPI.EDU>, bugsy@yoyodyne.WPI.EDU (Christopher Sean Moran) writes...
>Help me... I have a program called VORLAX which I need to compile.
>It was written and compiled originally on CDC FORTRAN IV.  All
>I have access to is Unix f77.  I have tried to compile it, but
>its a no go.  One problem is the first line
> 
>PROGRAM VORLAX(INPUT,OUTPUT, etc)
> 
>the compiler doesnt like the parenthesis after the program 
>declaration.  Past that there are no other problems.
> 
>I do get an executable after compiling if I take the stuff
>in the parenthesis out. But UNIX dumps my core every time
>I run the program.  Can anyone help me?
	Well, there is no problem with removing the stuff in the
parentheses.  Just be aware that it is a sign that the original Fortran
very likely didn't use OPEN statements to open the files used.  Most
UNIX Fortrans are a little more picky about OPENs being required.
	Core Dumps?  Well, this again is the Unix compiler being a little
more picky.  99% of the time when I have this problem (porting VAX Fortran
to a HP-UX platform) it is because of a "type mismatch" in function
or subroutine parameter passing.  In particular, on a VAX you can often
get away with passing a REAL*4 to a subroutine expecting a REAL*8 and
actually have a working program.  But it will do a core-dump on HP-UX just
about every time.  Another thing is that passing an integer "0" when a
subroutine expects a floating "0.0" (or "0d0") will usually work on
a VAX but also does core dumps on HP-UX.  Lots of old code did things like
this and often worked, even though they technically are bugs in the
source code!
	An important thing to note is that most NON-UNIX FORTRANS ASSUME
STATIC VARIABLE STORAGE IN SUBROUTINES, while UNIX FORTRANS USUALLY
ASSUME DYNAMIC STORAGE.  Check the manual for your compiler to see if you
can set it to default to static storage with a compilation switch.  The
alternative is to put a STATIC statement at the beginning of every
function or subroutine.
	A useful package for finding things like this is "FLINT", which
unfortunately is not (as far as I know) a public-domain program.  It's like
C's "lint", but instead for Fortran.  Does anyone know of a similar
product which *is* public-domain?


				Good luck!

				Tim (shoppa@erin.caltech.edu)

In article <27JAN199311453903@almach.caltech.edu> shoppa@almach.caltech.edu
(TIM SHOPPA) writes:
[text deleted]
>	A useful package for finding things like this is "FLINT", which
>unfortunately is not (as far as I know) a public-domain program.  It's like
>C's "lint", but instead for Fortran.  Does anyone know of a similar
>product which *is* public-domain?

You might try the ftnchek program available from netlib.

Is there reference to ftnchek in the FAQ?  If not, it might be worth adding.

-Ron Shepard
shepard@tcg.anl.gov

In article <1k6e6cINNmqo@bigboote.WPI.EDU> bugsy@yoyodyne.WPI.EDU (Christopher Sean Moran) writes:
>Help me... I have a program called VORLAX which I need to compile.
>It was written and compiled originally on CDC FORTRAN IV.  All
>I have access to is Unix f77.  I have tried to compile it, but
>its a no go.  One problem is the first line
>
>PROGRAM VORLAX(INPUT,OUTPUT, etc)
>

You can drop this line; INPUT, OUTPUT simply means the program reads 
from stdin and writes to stdout on units 5 and 6.  Too bad you didn't 
give the etc, I suppose it is something like TAPE7=FOO or so, which is 
equivalent to OPEN( 7, FILE = 'FOO' ).  Also beware of the crazy `file' 
structure on CDCs where you have several files in a file ;-), i.e., you 
can read beyond EOF and get more data.  Check if your code does anything
with END=label on READs.

>the compiler doesnt like the parenthesis after the program 
>declaration.  Past that there are no other problems.
>
>I do get an executable after compiling if I take the stuff
>in the parenthesis out. But UNIX dumps my core every time
>I run the program.  Can anyone help me?

Can you give a little more information?  Sometimes even Unix error
messages give a little more information.  Also try to compile -g (debug,
check you f77 man page for the correct switch) than a traceback might
have a line number in it.

Michael
-- 
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])

In article <1k6e6cINNmqo@bigboote.WPI.EDU>, bugsy@yoyodyne.WPI.EDU (Christopher Sean Moran) writes:
|>Help me... I have a program called VORLAX which I need to compile.
|>It was written and compiled originally on CDC FORTRAN IV.  All
|>I have access to is Unix f77.  I have tried to compile it, but
|>its a no go.  One problem is the first line
|>
|>PROGRAM VORLAX(INPUT,OUTPUT, etc)
|>
|>the compiler doesnt like the parenthesis after the program 
|>declaration.  Past that there are no other problems.

Ah, good old days!  The parenthesis above were a CDC extension
providing a sort of i/o redirection.  You could run the program by
something like
VORLAX,FOO,BAR.
which worked as vorlax < foo > bar would work on Unix.
But you could redirect many files with arbitrary fortran unit
numbers.

|>I do get an executable after compiling if I take the stuff
|>in the parenthesis out. But UNIX dumps my core every time
|>I run the program.  Can anyone help me?

As opposed to Fortran 90 vs Fortran 77, Fortran 77 is not downward 
compatible with Fortran 66 (CDC's FORTRAN IV is Fortran 66).
In particular, DO loops behave in a different way, and in Fortran 66
they are *always* executed at least once. So that
      A=0.
      DO 100 I=2,1
      A = A + 1.
100   CONTINUE
      B = B/A
would run fine with Fortran 66 but dump your core with Fortran 77.
Many compilers have an option to force the old-style behavior; look
for -onetrip or something like that.

Of course, your program may dump for other reasons.  The CDC was
a 60 (sic) bits machine using a 6-bit (ugh) character set, not ASCII,
so the potential for breakdowns related to COMMONs, EQUIVALENCEs,
characters stored in reals ... etc are huge.  I would suggest to check
accurately everything dealing with character manipulation.  As in
Fortran 66 there was no CHARACTER type, this is kinda fun. :-)
Good luck!
furio  
--
furio ercolessi    <furio@uiuc.edu>*    <furio@sissa.it>+
* materials research lab, uni illinois at urbana-champaign
+ intl school for advanced studies, trieste, italy   

"Change nothing and continue with immaculate consistency"
                                      [ Brian Eno, "Oblique Strategies" ]