From:	SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 30-OCT-1993 11:38:14.21
To:	EVERHART
CC:	
Subj:	AXP DEC FORTRAN - some porting observations

Date:    Sat, 30 Oct 1993 08:24:06 +0100
From:    "GWDGV1::MOELLER" <moeller@gwdgv1.dnet.gwdg.de>
To:      info-vax@sri.com
Subject: AXP DEC FORTRAN - some porting observations

I think I'll share some ('gotcha') experiences that I recently made
while porting a suite of quite old FORTRAN programs (not yet adapted
to VAX FORTRAN V6) to AXP/VMS:

FOR$RAB() - this is really silly. With VAX FORTRAN, FOR$RAB was an external
            function, and _had_ to be declared. Compiling such a program
            appears to work, but leads to the _very_ strange results that
            the executable will complain that it has to LINKed/NONATIVE.
            Reason:
		(a) FOR$RAB() is now an _intrinsic_ and	_must_not_ be declared!
                (b) for whatever reason, the old FORRTL has been left
                    in IMAGELIB.OLB, so the linker finds FOR$RAB in the
                    "compatibility mode" FORRTL_TV, therefore the complaint
                    only at execution time (don't honor it, the old
                    entry point won't work anyway).
            I find it pretty annoying that the required change calls for
            _incompatible_ program versions.

$FORIOSDEF - used to be a module in FORSYSDEF.TLB, but is no longer
             there. Workaround: include SYS$LIBRARY:FORIOSDEF.FOR -
             this also works on VAX (I used to think that including
             everything from the library was recommended?).

FOR$K_FAC_NO - "external" FOR$K_ constants were available on VAX
               in STARLET.OLB(FOR$ENODEF), but are no longer on ALPHA.
               This particular value [24, btw] used to come handy when
               converting IOSTAT values to condition codes (undocumented).

Finally, an insidious bug that looks like it wouldn't ever manifest itself
on a VAX: A function subprogram had a badly typed entry point, like

	INTEGER FUNCTION C1(I)
	INTEGER I
	...
	C1 = I
	RETURN
	...
	ENTRY C2(I)	! INTEGER declaration intended but missing;
	...		! C2 used nowhere in the subprogram
	C1 = I
	RETURN
	END

Traditionally, there had been no problem with this kind of program
(note that C2 is nowhere used, so it being not INTEGER didn't matter).
However, on ALPHA the compiler takes literally the (documented) rule
that the result returned by (REAL) C2 becomed undefined if an assigment
is made to the (INTEGER) C1 "alias", so C2() returns garbage.

Somehow I'd expected the compiler to diagnose that C2() could
_never_ return a "defined" result!

Anyway, enough reason to finally add IMPLICIT NONE to _all_ programs
that were still lacking it ...

Wolfgang J. Moeller, Tel. +49 551 201516 or -510, <moeller@gwdgv1.dnet.gwdg.de>
GWDG, D-37077 Goettingen, F.R.Germany            PSI%(0262)45050352008::MOELLER
Disclaimer: No claim intended! | <moeller@decus.decus.de>  <w.moeller@ieee.org>