Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ptsfa!ihnp4!homxb!mtuxo!mtune!quincy!icus!gil
From: gil@icus.UUCP (Gil Kloepfer Jr.)
Newsgroups: comp.lang.fortran,comp.sys.hp
Subject: Re: HP Fortran problems
Message-ID: <71@icus.UUCP>
Date: Mon, 30-Nov-87 10:10:26 EST
Article-I.D.: icus.71
Posted: Mon Nov 30 10:10:26 1987
Date-Received: Fri, 4-Dec-87 21:52:25 EST
References: <429@auvax.UUCP>
Reply-To: gil@icus.UUCP (Gil Kloepfer Jr.)
Distribution: na
Organization: ICUS Computer Group, Islip, NY
Lines: 50
Keywords: F66, HP9000, Series 500
Summary: Workaround for character data in numeric variables
Xref: mnetor comp.lang.fortran:346 comp.sys.hp:355

In article <429@auvax.UUCP> willis@auvax.UUCP (Tony Willis) writes:
>I would like to install a very large astronomical image processing
>system on an HP9000 series 500 workstation. The image processing
>system's code is largely written in F66 style and contains many
>coding gems of the form
>    REAL TEST
>    DATA TEST/'ABCD'/
>i.e. it uses the old F66 way of storing character data. Now most
>Unix style f77 compilers tend to produce warning messages which tell me
>that this coding style is hardly state-of-the-art, but they do keep
>going and compile the code. (At least they do on a Sun 3 and a VAX 785
>running Ultrix.) Unfortunately the HP9000 compiler produces a fatal
>error message stating that the data types are incompatible and does
>not complete the compilation. Therefore HP's compiler is clearly
>not upwardly compatible with f66 code.
>
>Now, this image processing system contains about 150,000 lines of code and
>I don't intend to rewrite it in f77 style by myself. So my question is -
>has anybody else encountered this problem and if so, can it be
>solved without rewriting the code? Is any kind of work-around solution
>available from HP?

Although I am not familiar with HP FORTRAN, I would think that you could
probably search-out the declarations of string variables (with your
editor) and find a list of variables which this problem happens in (look
for lines with an apostrophe in it).  Change these to CHARACTER*4 (see below)
and then compile (and get 100,000 more errors where you get a character
variable being assigned to a REAL).  A few passes this way should eventually
(but painfully) solve the problem.  I'm sure this is not a sound solution (so
no flames on this) .. but its the only one I could think of.

**NOTE**  Even more importantly -- does anyone KNOW what a REAL is defined
as in FORTRAN.  It occurred to me that, depending on the machine in
question, a REAL could be 2, 4, or 8 bytes long, limiting the number of
characters which may be stored in a REAL.  I am unaware of any clear
definition in the F66 standard (anyone else know?).

I know this doesn't answer the above question sufficiently, if at all.  I
thought it may be interesting to raise a few questions about this practice
in general.  I'm sure there's more than just one 150,000 line program
written line this.  Someone is probably stooped over a terminal right now
trying to make one of these dogs work!  Someone's answer to my question
may help too.


------------------------------------------------------------------------------
Gil Kloepfer, Jr.                                         USENET:  ...icus!gil
ICUS Computer Group, Systems Development
P.O. Box 1     Islip Terrace, New York  11752
------------------------------------------------------------------------------