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 ------------------------------------------------------------------------------