HDTenEightyP/NetNews huggingface dataset:
From: michael@chpc.utexas.edu (Michael Lemke)
Subject: Re: compiling FORTRAN IV on Unix f77
Organization: The University of Texas System - CHPC
Date: Wed, 27 Jan 93 21:04:43 GMT

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])
Newsgroups: comp.lang.fortran
From: aduncan@rhea.trl.OZ.AU (Allan Duncan)
Subject: Re: dbx headache
Organization: Telecom Research Labs, Melbourne, Australia
Date: Tue, 26 Jan 1993 11:35:19 GMT

From article <1993Jan22.171934.15193@midway.uchicago.edu>, by jfu2@kimbark.uchicago.edu (Carlo Graziani):

[ tales of woe deleted]
 
> I'm no expert on the subject, but I suspect that the problem has to do
> with the fact that dbx was not designed as a fortran debugger, and that
> it was "fortranized" by a series of awkward patches.  Unfortunately, I
> am aware of no alternative available for Unix workstations.  I feel that
> this is a serious limitation in the developement environment offered by
> vendors of fortran packages for unix.
> 
> I can't say I miss working on a VAX, but I sure do miss the VAX fortran
> environment.

You have made an unwarranted generalization here.  Unix != BSD  :-)
The AT&T equivalent is sdb, and is much neater than dbx.  It works with
Fortran (well moderately so), although it is still a bit kludgey.
Allan Duncan		ACSnet	 a.duncan@trl.oz
(+613) 253 6708		Internet a.duncan@trl.oz.au
Fax    253 6664		UUCP	 {uunet,hplabs,ukc}!munnari!trl.oz.au!a.duncan
    Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.
From: shoppa@almach.caltech.edu (TIM SHOPPA)
Newsgroups: comp.lang.fortran
Subject: Re: compiling FORTRAN IV on Unix f77
Date: 27 Jan 1993 11:45 PST
Organization: California Institute of Technology
Distribution: world
NNTP-Posting-Host: almach.caltech.edu
News-Software: VAX/VMS VNEWS 1.41    

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)
Newsgroups: comp.lang.fortran
From: mark@sun1x.actc.res.utc.com (Mark Stucky)
Subject: Re: IAND(I,J) IOR(I,J) ???
Organization: United Technologies Research Center
Date: Mon, 25 Jan 1993 19:12:36 GMT

kroeker@oc1.oc.chemie.th-darmstadt.de (Martin Kroeker) writes:
: Could somebody please point me to a fortran source code that provides the
: functionality of the non-standard functions IAND, IOR, IEOR and BTEST ?
: I am trying to port a database application from a soon-to-be-junked IBM
: mainframe to a workstation where the fortran compiler is in fact f2c, and my
: own attempts at these bit-handling functions have failed miserably.
: Thanks in advance,
: Martin

Here's some...

      INTEGER*2 FUNCTION IAND(I1,I2)
C BITWISE LOGICAL FUNCTIONS - MAY HAVE TO BE CHANGED
C  ACCORDING TO A GIVEN SYSTEM'S IMPLEMENTATION
      INTEGER*2 I1,I2
      IAND = I1.AND.I2
      RETURN
      END

      INTEGER*2 FUNCTION IXOR(I1,I2)
      INTEGER*2 I1,I2
      IXOR = I1.XOR.I2
      RETURN
      END

      INTEGER*2 FUNCTION IOR(I1,I2)
      INTEGER*2 I1,I2
      IOR = I1.OR.I2
      RETURN
      END

      INTEGER*2 FUNCTION INOT(I1)
      INTEGER*2 I1
      INOT = .NOT.I1
      RETURN
      END

-- 
------------------------------------------------------------------------------
| Mark Stucky                         | Email:                               |
| United Technologies Research Center |     mark@ardnt1.res.utc.com          |
| East Hartford, CT.                  |or   mbs@utrcgw.res.utc.com           |
Newsgroups: comp.lang.fortran,comp.sys.dec,comp.sys.hp,comp.sys.mips.comp.sys.sgi
From: glenr@aruba.UUCP (Glen Reesor)
Subject: 64bit Floating Point Performance
Date: Fri, 22 Jan 1993 23:33:59 GMT
Reply-To: aruba!glenr@uu2.psi.com
Organization: Project Zed
Keywords: Precision, Floating Point

I am looking for 64-bit floating point performance figures in order to 
determine what workstation to buy.  The application is in thermalhydraulics
and 64-bit precision is required.  This application is currently running
on a Cyber mainframe and one run can take on the order of days to complete.
Because of this, graphics performance and disk performance are a 
non-issue.

The machines I've been told would be good to consider are:

- HP 9000/7xx  (32-bit)
- IBM RS6000   (32-bit)
- Sun          (32-bit)
- SGI Crimson  (64-bit)
- Dec Alpha (Running Unix)  (64-bit)

Now, 64 bits precision is required, but a 64-bit chip will not necessarily
be required, since one of the 32-bit architectures could be sufficiently
fast to outperform a 64-bit one.  BTW, the application is written in Fortran.

I am looking for real-world experience with any of these platforms and thus
advice on relative floating point speeds.

Finally, the price should be in the $50K range.

Any advice would be greatly appreciated.  Please respond via e-mail.  I
will summarize to the net if there is interest.

-- 
Glen Reesor                       | Internet Style:  aruba!glenr@uu2.psi.com 
                                  | UUCP :  ...!uunet!aruba!glenr
Organization: Queen's University at Kingston
Date: Thu, 21 Jan 1993 23:45:29 EST
From: <MATOVICM@QUCDN.QueensU.CA>
Newsgroups: comp.lang.fortran
Subject: dbx headache

I'm fed up with dbx (SGI, IRIX 3.3.2, IRIX 4.0.1) when debugging fortran
programs. Examining arrays is pain in a neck unless you deal with the
size a(3,3) or similar. Is there any way to say e.g.
  print a from 155 to 175 (and possibly to specify the increment).
Or, is there any other UNIX (public domain) debugger that can handle
arrays frinedly?
From: jfu2@kimbark.uchicago.edu (Carlo Graziani)
Newsgroups: comp.lang.fortran
Subject: Re: dbx headache
Date: 22 Jan 93 17:19:34 GMT
Reply-To: jfu2@midway.uchicago.edu
Organization: University of Chicago

In article <1993Jan22.135940.9828@msdrl.com> ball@msdrl.com (Richard Ball) writes:
>MATOVICM@QUCDN.QueensU.CA () writes:
>: I'm fed up with dbx (SGI, IRIX 3.3.2, IRIX 4.0.1) when debugging fortran
>: programs. Examining arrays is pain in a neck unless you deal with the
>: size a(3,3) or similar. Is there any way to say e.g.
>:   print a from 155 to 175 (and possibly to specify the increment).
>: Or, is there any other UNIX (public domain) debugger that can handle
>: arrays frinedly?
>
>your dbx should let you do
>&a(155)/20f
>to print the 20 elements of a in floating point format starting at element
>155. It's not the most friendly way but it is better than listing the whole
>thing.

Yeah, but sadly this only allows contiguously stored array elements to
be displayed.  It would be nice to be able to display _logically_ contiguous
elements, even when they are not stored contiguously i.e. "print A(1,7-15)",
or some such syntax.

More generally speaking, dbx is a relentless headache when debugging
fortran code.  In its incarnation on sun4's, locating trapped floating point
exceptions requires laborious procedures that work haphazardly, at best.
Often operation which might be expected to generate floating point
exceptions (logs of negative numbers, for example) generate segmentation
violations instead, and dbx appears to halt in a part of the code unrelated
to where the problem occurred.

Case sensitivity is another hassle.  dbx may be set to be case insensitive
if required, but for reasons that defy comprehension this affects the
way dbx understands filenames as well, so that after a "dbxenv case
insensitive" it is impossible (for example) to change to a directory
with a partially capitalized name.

I'm no expert on the subject, but I suspect that the problem has to do
with the fact that dbx was not designed as a fortran debugger, and that
it was "fortranized" by a series of awkward patches.  Unfortunately, I
am aware of no alternative available for Unix workstations.  I feel that
this is a serious limitation in the developement environment offered by
vendors of fortran packages for unix.

I can't say I miss working on a VAX, but I sure do miss the VAX fortran
environment.

Carlo

-----------------------------------------------------------------------------
Carlo Graziani           |   Warning:  some of the above may not be a fully  |
Dept. of Physics         |   correct representation of profound cosmic truth.|
University of Chicago    |                                                   |
                         |  "It's fun to have fun, but you have to know how!"|
carlo@nu.uchicago.edu    |                           -The Cat in the Hat     |
-----------------------------------------------------------------------------
Newsgroups: comp.lang.fortran
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: Poor programming (was: Block Data is evil)
Organization: Los Alamos National Laboratory
Date: Mon, 25 Jan 1993 18:38:43 GMT

In article <C1BEIn.8MA@umassd.edu>, hshubs@cis.umassd.edu (Howard S Shubs) writes:
|> In <1993Jan23.151052.6593@hubcap.clemson.edu> jtbell@hubcap.clemson.edu (Jon Bell) writes:
|> 
|> >In article <C1AMpC.BAt@umassd.edu> hshubs@cis.umassd.edu (Howard S Shubs) writes:
|> [...]
|> >>You're not seriously suggesting that this be used in production code,
|> >>are you?  If you are, is this intended as job security?
|> 
|> >It's already been done.  When I was a grad student in experimental
|> >particle physics, I worked with CERN's HYDRA library, which implemented
|> >dynamic memory allocation in FORTRAN using the same basic idea.  I 
|> >think this package is still widely used in particle physics.
|> 
|> That's meaningless.  Just because something has been done poorly is not
|> a reason to continue to do it poorly.  Someone has to maintain that code.

I agree that the method I wrote is not desirable if an alternative
is available.  This is one of the reasons I dislike C - it handles
pointered arrays almost identically to what I gave.  In fact, as I 
pointed out, with the proper preprocessor you can make the Fortran
version *look* syntactically identical to the C version.  The only
difference would be that Fortran would still have to allocate it's
memory statically (and, in most implementations, you do not really
even have to do that).

Among the things Fortran 90 does correctly are ALLOCATABLE arrays.
Unfortunately, they chose to *also* support pointers.

-- 
J. Giles
Newsgroups: comp.lang.fortran
From: pmurphy@nrao.edu (Pat Murphy)
Subject: Re: How to get command line arguments from unix with FORTRAN?
Organization: National Radio Astronomy Observatory
Date: Tue, 26 Jan 1993 17:18:47 GMT

"PLN" == Patrick L. Nolan <pln@egret0.Stanford.EDU> writes:

PLN> Peter Kocks (kocks@leland.Stanford.EDU) wrote:

PLN> : Can someone tell me how to read the command line arguments of
PLN> : a unix command line from with FORTRAN.  Something presumably similar
PLN> : to the c
PLN> : 
PLN> : main(int argc, char **argv){
PLN> : }
PLN> : 
PLN> It probably varies with the flavor of unix.  On a Sun, you have:

PLN>      subroutine getarg ( k, arg )
PLN>      character*(*) arg
PLN>  
PLN>      function iargc ()

A brief experiment with telnet shows that his posting machine is not a
Sun: "ULTRIX V4.2A (Rev. 47)".  My f77 info for Ultrix (4.0),
fortunately shows getarg identical to the above.  However I know that
for other flavors of unix it is different.  For example, HP-UX uses a
function IGETARG with three arguments.

				- Pat
--
==========================================================================
| Patrick P. Murphy, Ph.D.                Scientific Programming Analyst |
| National Radio Astronomy Observatory    Net:       pmurphy@nrao.edu    |
| 520 Edgemont Road                       Phone:     (804) 296-0372      |
| Charlottesville, VA 22903-2475          VoiceMail: (804) 980-5889      |
|      "I don't believe in the no-win scenario"  --- James T. Kirk       |
==========================================================================
Newsgroups: comp.lang.fortran
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: Block Data is evil
Organization: Los Alamos National Laboratory
Date: Fri, 22 Jan 1993 18:31:06 GMT

In article <1993Jan21.074755.14939@arcetri.astro.it>, lfini@sisifo (Luca Fini) writes:
|> W. Donald Rolph (a722756@roper.mc.ti.com) wrote:
|> : 
|> : Equivalence is in some cases the only possiblity for run time memory allocation
|> :
|> 
|> Equivalence is *not* a run rime memory allocation, you simply call the
|> same memory area with different names (and possibly use it as different
|> data types).

Yes, and that permits you to do run-time management of a statically
allocated "maximum" space.  You figure out what the maximum memory
you ever need is and you statically allocate that much:

      PARAMETER (MAXMEM=1000000)
      COMMON /MEMORY/ MEM(MAXMEM)

This reserves one million integer sized words.  Now, you can write
a MALLOC routine which returns avalable space from within this array
in the form of an index (you actually have two mallocs, one for
integers and reals, the other for complex and doubles - since the
indices must be scaled differently).  To use:

      PARAMETER (MAXMEM=1000000)
      COMMON /MEMORY/ MEM(MAXMEM)
      ...
      REAL RMEM(1)			!declare length one, you use more
      EQUIVALENCE (MEM(1),RMEM(1))
      ...
      RA = MALLOC(100)			!set RA to index of a 100-long block
      ...
      DO 10 I=0,99
         RMEM(RA+I) = ...
      ...
10    CONTINUE

You could even write a preprocessor which allowed you to write RA[I]
and the processor would automatically turn it into RMEM(RA+I).  (Note
the similarity to the C rule of turning a[i] into *(a+i) - the only
difference is that C calls the common memory area `*' instead of `MEM'.)
To use MEM as a double or complex, you simply declare DMEM and CMEM
arrays and equivalence them to MEM as well.  You should then use DALLOC
to reserve space and your `pointers' should be named beginning with D
or C so the preprocessor can figure out which equivalenced array to use.

-- 
J. Giles
From: jrbd@craycos.com (James Davies)
Newsgroups: comp.lang.fortran
Subject: Re: Compiler groups working on real apps?
Date: 25 Jan 93 17:15:44 GMT
Organization: Cray Computer Corporation

In article <C1Cnq5.1zt@news.cso.uiuc.edu> ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi) writes:
>In article <1993Jan23.003639.13681@craycos.com>, jrbd@craycos.com (James Davies) writes:
>|>In article <C19wHr.GF3@news.cso.uiuc.edu> ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi) writes:
>|>
>|>>This is probably too much to ask.  But I am wondering.  Maybe any one of
>|>>us (users) could spend some time in putting together some "typical" code,
>|>>containing a simplified version of the loops where our programs spend
>|>>most of the time.
>|>
>|>You've just described the Livermore Loops.
>
>After seeing this comment, I fired up xnetlib, downloaded the Livermore
>loops and looked at them.  I must admit I was not familiar with them.
>While there is certainly an interesting variety of codes in there (there are 24 
>different 'kernels'), at a first glance I was not able to locate something that 
>I feel represents the kind of codes I am dealing with.
>
>My applications involve classical molecular dynamics (i.e., interacting atoms 
>treated like classical masses and moved by time integration of F=ma).

My previous answer was a bit flip, I suppose, but basically there have been
lots of benchmarks floating around for decades now, and they tend to be
used primarily for marketting ("New XYZ Workstation Achieves 250 SPECmarks!!")
or as argument fodder ("Yeah, but they're using SPEC88, which was too easy
to cook by using a smart compiler!  They only get 127 on the SPEC93 suite,
but our new ABC9000 gets 172 SPEC93marks!").  For what it's worth, the
Perfect Club suite is a collection of application programs that was supposed
to avoid compiler cheating, and also help advance compiler technology by
encouraging sharing of techniques, but since the results don't boil down to a
single number that can be easily quoted by marketroids most everyone basically
ignores it.  Perfect includes one code that is a molecular-dynamics
simulation (MDG).
Newsgroups: comp.lang.fortran
From: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Subject: Re: calling a Fortran subroutine from a C program
Reply-To: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Organization: MRL - UIUC
Date: Fri, 22 Jan 1993 01:50:56 GMT

In article <9229@lhdsy1.lahabra.chevron.com>, hwrvo@kato.lahabra.chevron.com (W.R. Volz) writes:
|>In article <1jmqdaINN11g@mudhoney.mathcs.emory.edu>, swhite@mathcs.emory.edu (Scott White)
|>writes:
|>|> Can someone please tell me how to call a Fortran subroutine from a C program?
|> ...
|>Some other things to think about: ...

This contribution by Bill Volz should go in the FAQ file at once!!!!

--
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" ]
From: v070rajv@ubvmsb.cc.buffalo.edu (Matthew Lewis)
Newsgroups: comp.lang.fortran
Subject: PD Fortran Compilers
Date: 27 Jan 93 04:26:00 GMT
Organization: University at Buffalo
News-Software: VAX/VMS VNEWS 1.41


Does anyone know of any FTP sites that have a  fortran compiler? I tried the
one at SIMTEL and oak.oakland.edu, but the one they have debugs in german of
all things!
From: stallcup@stsci.edu (Scott Stallcup)
Newsgroups: comp.lang.fortran
Subject: Reformatter for FORTRAN code
Date: 27 Jan 93 21:00:33 GMT
Organization: Space Telescope Science Institute
X-Newsreader: TIN [version 1.1 PL6]


 We are looking for any tools to reformat FORTRAN code
 (Sometimes called a pretty-printer).  Public domain
 or commercial programs will be considered.  Preferably,
 the program will be able to handle VAX/VMS extensions.

 Please post or return mail any suggestions, FTP sites, etc.

 Thanks,

 --------------------------------------------------------
 Scott Stallcup                     (stallcup@stsci.edu)
 Space Telescope Science Institute
From: mpe@shamash.cdc.com ()
Newsgroups: comp.lang.fortran
Subject: Fortran compiler source code <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Date: 26 Jan 93 19:53:07 GMT

I'm looking for a public domain version of a fortran compiler.  Either F77
or F90 (or any subset there-of) will do. 

I don't care which processor family the final object code targets since
I plan to re-write the "back-end" to suit my own process design project.
 
Any help or pointers are welcomed.  Thank you for any help you might be able
to provide.
 
mpe@procyon.cdev.com
 
Newsgroups: comp.lang.fortran
From: dafnioti@cae.wisc.edu (Petros Dafniotis)
Subject: Help with UNIX f77 file buffer system
Organization: U of Wisconsin-Madison College of Engineering
Date: 25 Jan 93 09:19:37 CST
Summary: Need to flush buffer after each write statement 

Hello netters,

  I know very little about UNIX (in fact I am using VMS for almost 9yrs now).
A friend of mine had the following problem:
"His program (all written in FORTRAN by 1-2 people years ago) takes quite
some time to finish. He is writing info produced at
run time to 2-3 output files. However, 90% of the runs are proved to be
useless quite soon; so he uses CTRL-C to abort execution. But then he finds
no info in the output files. I am guessing that the UNIX file buffer system
still keeps these numbers in the buffer and what he needs is to flush the
buffers after each single write. Could someone tell me how can this be
accomplished in UNIX? (he is using HP-RISC and SUN SPARC-I workstations)."

  I would appreciate any help/comments (replies either by e-mail or in the
news are fine). Thank you,

				Petros Dafniotis
				Chem Engr Dept, UW-Madison
			e-mail: dafnioti@cae.wisc.edu

PS: I managed to do that by using really a C function to do all open/fprintf/
    fflush/close commands. But I would prefer a FORTRAN way (if possible).
Newsgroups: comp.lang.fortran