HDTenEightyP/NetNews huggingface dataset:
From: akearns@ll.mit.edu ( Adam Kearns)
Newsgroups: comp.lang.fortran
Subject: Reading C output in FORTRAN
Date: 24 Jul 92 17:22:54 GMT
Organization: MIT Lincoln Laboratory


	Hi. We have some files on a VAX that are STREAM_LF type, and we would
like to read them in FORTRAN using the READ command.  The file has a 
fixed length of 16384 bytes.  The problem is that using the READ command
doesn't seem to move the file pointer to the where it stopped reading, so
we read the same data over again.  We have a way using QIO to read in the
file, but that requires computing the number of disk blocks we read and
starting from there.  This technique is rather inconvienent, espically
if a record ends in the middle of a disk block (for a different file, 
obviously this one does).  It would be nice to be able to use the READ 
command and have the program keep track of where it is in the file
like you can in VAX C.  Any suggestions would be appreciated.

					Thanks for your help,	
					Adam Kearns
					akearns@ll.mit.edu
From: burley@albert.gnu.ai.mit.edu (Craig Burley)
Newsgroups: comp.lang.fortran
Subject: Re: why are fortran binaries so large?
Date: 25 Jul 92 02:13:36 GMT
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
In-reply-to: burley@geech.gnu.ai.mit.edu's message of 24 Jul 92 17:02:28 GMT

In article <BURLEY.92Jul24130228@geech.gnu.ai.mit.edu> burley@geech.gnu.ai.mit.edu (Craig Burley) writes:

	 SUBROUTINE NEXT(N)
	 INTEGER N,NEXTN
	 LOGICAL FIRST
	 DATA FIRST/.TRUE./
	 IF (FIRST) NEXTN = 0
----
Oops, please insert

      FIRST = .FALSE.

here!
----
	 NEXTN = NEXTN + 1
	 N = NEXTN
	 END
--

James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu
Member of the League for Programming Freedom (LPF)
Newsgroups: comp.lang.fortran
From: lfm@pgroup.com (Larry Meadows)
Subject: Re: 64-bit integers from Sun f77
Date: Sat, 25 Jul 1992 16:05:33 GMT
Organization: The Portland Group, Portland, OR

In article <9080023@hpfcso.FC.HP.COM> kauth@hpfcso.FC.HP.COM (Joan Kauth) writes:
>I can't answer your original question, but am curious as to why 64-bit
>integers are important for Fortran users, so I would like to pose a counter
>question.
>
>Why do you need 64-bit integers?
>I.e. What do you use integers for that requires > 32 bits?
>
>Some possibilities come to mind:
>
> o For importability from systems whose default integer size is 64-bits.
This is often why users ask us for 64-bit integers.  Porting Cray code.
Many of them would probably be satisfied if 32-bit integers took up 8
bytes, this is the solution implemented by several compilers.

> o For time or money representation.
> o For representation of quantities (such as distance or length) which more
>   naturally would be REAL, but integer operations are faster.
> o For more bit fields in an integer for use as flags.
>
>Or ??
  o Because we really have arrays that take up more than 4GB of space.
    Consider a MPP machine with 1024 nodes each with 1GB of memory --
    or even 64MB of memory (or even 4MB of memory :-).  You may really want
    to index that array in a linear fashion.
  o Because we have file systems with many GB (TB?) and want to address
    them uniformly (flat addressing).
[ I've heard both these from users ]
-- 
Larry Meadows		The Portland Group
lfm@pgroup.com
From: wmitchel@fergie.dnet.ge.com (Bill Mitchell)
Newsgroups: comp.lang.fortran
Subject: Re: SUMMARY: Partial Diff. Eqn's. Thanks to all
Date: 27 Jul 92 13:27:43 GMT
Organization: GE Advanced Technology Labs

In article <24JUL92.12390271@wl.aecl.ca>, harrisp@wl.aecl.ca writes:
|> 
|> useful. TOMS stands for Transactions of the Mathematical Society (I believe)
|> and algorithms related to published articles are available on NETLIB
|> 
TOMS stands for Transactions on Mathematical Software.  It is published
by ACM (Associations for Computing Machinery)

Bill Mitchell
From: roth@oasys.dt.navy.mil (Pete Roth)
Newsgroups: comp.lang.fortran
Subject: Re: Wanted : Structure chart generator for F
Date: 29 Jul 92 18:28:09 GMT
Reply-To: roth@oasys.dt.navy.mil (Pete Roth)
Organization: The David Taylor Model Basin

In comp.lang.fortran, zinckt@wl.aecl.ca writes:
>
>I am looking for  code that creates a structure chart from F77 code.
[...]

can you be a bit more specific... what do YOU mean by a "structure chart"?

regards, pete
- - - - - - - - - - - - - - - - - - - - - - - - - -
Peter N Roth      roth@oasys.dt.navy.mil
"Never argue with someone who buys ink by the barrel." - Daniel Janal.
From: jnixon@spam.ua.oz (John Nixon)
Newsgroups: comp.lang.fortran
Subject: Re: Portability of DIRECT UNFORMATTED data files?
Summary: CRAY IEEE = Sun C
Keywords: CRAY, IEEE, SUN, C, DIRECT, UNFORMATTED
Date: 30 Jul 92 23:55:26 GMT
Followup-To: comp.lang.fortran
Organization: Statistics, Pure & Applied Mathematics, University of Adelaide

In article <Bs5F3H.AB0@news.udel.edu> mccalpin@perelandra.cms.udel.edu (John D. McCalpin) writes:

>There is a growing range of machines for which Fortran direct access files
>use the same internal format.  Right now I share Fortran DA files between
>Sun, Silicon Graphics, and IBM RS/6000 machines completely transparently.

Add to the list CRAY (see below).

>(Note: the OPEN statement on the SGI may differ, since the RECL= parameter
>is in 32-bit words, while Sun & IBM use a RECL of bytes.)

This is correct for the CRAY too, you need the OS to do 64 bit to 32 bit
translation.

>These machines also use identical formats for Fortran sequential unformatted
>files.

Not so for the CRAY.

>I am told that there exist options in Cray Fortran to output IEEE binary
>files.  I do not know if they implement exact compatibility with the
>Sun/SGI/IBM machines for DA files or for sequential unformatted files.

Yes (see above), but you need to either read them with a C program, or
use direct access.  For an answer to this question, see my previous
posting.

--
John Nixon {Research Dude} jnixon@spam.maths.adelaide.edu.au [08 228-5407]
Department of Applied Mathematics, The University of Adelaide, SA, AUSTRALIA
"Anonymous Techno Act" Sample of the Week: "Music & noise.  Noise & music."
Newsgroups: comp.lang.fortran
From: aswx266@chpc.utexas.edu (Michael Lemke)
Subject: Re: DIR from within VAX Fortran
Keywords: DIR VAX
Organization: The University of Texas System - CHPC
Date: Wed, 29 Jul 92 23:00:47 GMT

In article <1992Jul29.212842.28989@constellation.ecn.uoknor.edu> david-bourne@uokhsc.edu (David Bourne) writes:
>I have written a program in FORTRAN for the Mac, IBM, and am now porting it 
>to the VAX environment. It runs OK with a few problems. At one point I ask 
>the user to enter a file name. If the user gets it wrong and the file doesn't 
>exist I can give the user the opportunity to do a directory call. With the 
>Mac its a standard toolbx call. With MS FORTRAN 5.0 on the IBM I use a pause 
>statment which allows the users to enter the DIR *.DAT for example to do a 
>directory before reasking for the file name. On the VAX the pause only allows 
>the user to enter continue. Anything else aborts the program. Does anyone 
>have suggestions for a work around. Thanks.

	I think a SPAWN is also ok; either just SPAWN and do whatever
you like (use LOGOUT to go back to your curent process that runs your 
program) or do SPAWN DIR and then the CONTINUE.

	Better solution would be to code something around the 
LIB$FIND_FILE call in your code.  See HELP RTL LIB LIB$FIND_FILE.

-- 
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
Newsgroups: comp.lang.fortran
From: zinckt@wl.aecl.ca
Subject: Structure Chart for VAX/VMS F77
Organization: AECL RESEARCH
Date: Wed, 29 Jul 1992 20:30:48 GMT

Hello, 

Sorry about the confusion, maybe I can explain what I am want a little better. 
I am looking for a tool that wil produce a dependancy chart of subroutine calls
and data passing from subroutine and functions. I am documenting F77 code which 
consists of 20 or so subroutines/modules. I want to be able to visualize the 
calling sequence and the data flow a little easier. Is there a tool that could
help me do this? I am working on VAX/VMS with F77 and C. 

Thanx for any help.

	Tom

----------------------------
T.R.A. Zinck
ATOMIC ENERGY CANADA LIMITED
Whiteshell Labs, Pinawa, Manitoba, CANADA
zinckt@wl.aecl.ca
From: djm@hpfcso.FC.HP.COM (Dan Magenheimer)
Date: Tue, 28 Jul 1992 18:13:00 GMT
Subject: CALLING UNIX (PORTABLY) FROM FORTRAN
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.lang.fortran

WANT TO CALL UNIX PORTABLY FROM FORTRAN?  Read this:

(Since only a small percentage of Fortran programmers read notes, please
forward this message to others who might be interested.  Thanks!)

The IEEE Standards Board has recently approved IEEE Std 1003.9 aka
"Fortran Bindings for POSIX".  Published copies should be available
in a couple of months from IEEE.

As an ex-member of the committee, I'd like to poll the user community
to determine 1) whether you will use it, and 2) whether you will be
encouraging your system and/or Fortran vendors to provide it.

What is "it"?  Here's a brief description:

IEEE Std 1003.9 is/contains/standardizes:

o A portable way to call all POSIX system calls.  The standard uses
  FORTRAN 77 standard features with only one extension -- long subroutine
  names.  Examples: chmod, chdir, pipe, fork/exec, signal routines, getpid.
o Access to system constants, both static and dynamic.  Examples: LINK_MAX,
  PIPE_BUF, PATH_MAX, stat modes, open modes.
o Access to system structures, such as stat.
o A POSIX-based FORTRAN I/O layer which allows (portable) usage of files,
  pipes, and devices that do not use record-based FORTRAN conventions.
  Requirements are also defined for interactions between record-based
  FORTRAN I/O and POSIX-based FORTRAN I/O.  Also, getc/putc equivalents.
o Environment access routines (e.g. command line arguments, ENV access)
o MIL-STD-like support routines (e.g. ior, and, not)
o Extensibility.  All interfaces use a consistent set of conventions that
  can be easily applied by a vendor to non-POSIX calls.

Much of this of course already exists but differs from vendor to vendor
and is therefore not portable.  IEEE Std 1003.9 encourages portability.
Of course, portability is not obtained unless the standard is supported
by vendors, and it won't be supported by vendors unless users (YOU!)
ask for it.

Caveats:  As you will see if you look at the standard (and as may be pointed
out by some who opposed the standard), the standard contains some
compromises that may be considered less than aesthetic.  This tends to be
true of any standard, but the reasoning for each decision is carefully
described in the Rationale appendix to the standard. Also, some areas
that might have proved useful to standardize were left out to increase
consensus.  These may be standardized by future standards committees.

Still, we're proud that we were able to complete the standards process
and would like to find out if and how widely it would be used.  So,
please reply to this message (email or notes/news) with:

   1) Will you use it if its available? (Optional: How? Why? When?)
   2) Will you be encouraging your system/Fortran vendor to provide it?

I will openly post email responses.

Finally, if you are interested in participating in related POSIX/FORTRAN
standardization activities, please contact Michael Hannah, mjhanna@sandia.org.

				Thanks,
				Dan Magenheimer
				POSIX 1003.9 (ex-)Technical Editor
				djm@fc.hp.com
				FAX: 303-229-6409
From: ccsdhd@gdt.bath.ac.uk (Dennis Davis)
Newsgroups: comp.lang.fortran
Subject: Re: recursive I/O
Date: 22 Jul 92 11:27:43 GMT
Organization: Bath University Computing Services, UK

In article <1992Jul21.223157.2775@ccu1.aukuni.ac.nz> ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig) writes:
>Is the following legal F77?  It works on the UNIX box I'm on at the
>moment, but I can imagine trouble with architectures which do not use
>a stack for argument passing, for example /370. 
>
>C This assumes channels 6 and 0 are preconnected
>      PROGRAM MAIN
>      WRITE (6,*) FCN(2.3)
>      END
>      FUNCTION FCN(A)
>      IF (A.GT.2.) WRITE (0,*) 'Something horrible happened'
>      FCN = 2. - A
>      END

This is illegal Fortran. See Section 12.11 of the Standard which
states:

   "A function must not be referenced within an expression
    appearing anywhere in an input/output statement if such a
    reference causes an input/output statement to be executed."

I'd regard your program as illegal as it stands.  If the argument
to the function were less than or equal to 2, I'd regard the
program as legal.

Writing programs which can flip-flop in and out of legality is, in
my opinion, a rather dubious practice.  Unfortunately they are all
too easy to write.  For example the two lines of code:

      READ (5, *) I, J, K, L, M, N
      A(I:J) = A(K:L) // A(M:N)

is legal or illegal depending upon the values of the integer
variables read in.  See Section 10.4 of the Standard.
-- 
Dennis Davis, BUCS, University of Bath, Bath, BA2 7AY, United Kingdom
D.H.Davis@bath.ac.uk     ...!uunet!mcsun!ukc!gdr!D.H.Davis
Newsgroups: comp.lang.fortran
From:  al@seacost.pccentre.msk.su (Post)
Distribution: world
Subject: Can man You HELP ME ?
Organization: Small Venture INFORM
Date: Fri, 31 Jul 92 12:36:21 +0300
Newsgroups: comp.lang.fortran

In comp.lang.fortran, system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes:

> In article <OHL.92Jul23231746@ips105.desy.de> ohl@ips105.desy.de (Thorsten Ohl) writes:
> >
> >At least on Apollos and HP-UX boxes you can trick the compiler to
> >allocate the offending array in the BSS segment by putting it into a
> >COMMON block.  Yes, it's a hack, but it can reduce the size of your
> >binaries tremendously.
> 
> If you use the '-K' option (to save and zero your variables), HP-UX
> will always create a huge executable; Apollo/Domain, SGI and IBM
> RS/6000 do not even when SAVE (or the compiler switch equivalent) is
> used, unless of course DATA is used to actually initialize
> the variables/arrays, when there is no alternative except to write
> them into the executable. Otherwise the COMMON trick does the job.

The large executable size with -K on HP-UX is a result of variables
sometimes ending up in the data segment when they really belong in
BSS. For example:

	REAL A(1000)
	REAL X(10)
	DATA X/10*1.0/
	...
	END

When compiled with -K, variable X should end up in the data segment, and
variable A in BSS.  However, both A and X may be put in data, causing the
executable to be larger than necessary.

This problem has been fixed in the HP-UX Fortran compiler and will
ship with the next release.

Alan Meyer
Hewlett-Packard
Colorado Language Lab
acmeyer@fc.hp.com

"These are my own opinions ..."
From: indran@ac.dal.ca
Newsgroups: comp.lang.fortran
Subject: Week days
Date: 21 Jul 92 20:05:31 -0300
Organization: Dalhousie University, Halifax, Nova Scotia, Canada


Hello
	I am running a fortran program which is relativly huge and 
require nearly 30 hrs of cpu time, on VAX 8800.TDuring 
week days (when there are many users) the program crashes 
very easly with the error arithematic overflow. The same 
program without any change will run during weekends. Could 
someone tell me what is going on ? If the results depend on 
week days can I trust them ?. 


Hope this is the right news grupe to ask this question




Thanks
ravi
From: mccalpin@perelandra.cms.udel.edu (John D. McCalpin)
Newsgroups: comp.lang.fortran
Subject: Re: Portability of DIRECT UNFORMATTED data files?
Date: 29 Jul 92 11:40:28 GMT
Organization: College of Marine Studies, U. Del.

In article <1992Jul29.111524.1@lure.latrobe.edu.au> matap@lure.latrobe.edu.au (Andrej Panjkov, La Trobe Maths) writes:
>What does the standard say about the internal format of DIRECT UNFORMATTED
>data files? 

I have not looked, but I suspect that the standard says nothing useful
for portability here.

>Will these be portable between systems?  (ie is a D/U file written by
>a Fortran program on one system readable by a Fortran program on another?)

There is a growing range of machines for which Fortran direct access files
use the same internal format.  Right now I share Fortran DA files between
Sun, Silicon Graphics, and IBM RS/6000 machines completely transparently.

(Note: the OPEN statement on the SGI may differ, since the RECL= parameter
is in 32-bit words, while Sun & IBM use a RECL of bytes.)

These machines also use identical formats for Fortran sequential unformatted
files.

Many other machines are definitely *not* the same format, such as the
DECstations, which have their bytes swapped.  I think that Stardent
does some funny swapping as well - perhaps on half-words?

I am told that there exist options in Cray Fortran to output IEEE binary
files.  I do not know if they implement exact compatibility with the 
Sun/SGI/IBM machines for DA files or for sequential unformatted files.
-- 
--
John D. McCalpin                        mccalpin@perelandra.cms.udel.edu
Assistant Professor                     mccalpin@brahms.udel.edu
College of Marine Studies, U. Del.      John.McCalpin@mvs.udel.edu
Newsgroups: comp.lang.fortran
From: simon@giaec.cc.monash.edu.au (simon shields)
Subject: dynamic arrays in fortran
Keywords: f77,HP-UX,720
Organization: Monash University, Melb., Australia.
Date: Tue, 28 Jul 1992 23:18:04 GMT

SYSTEM: HP-UX giaec A.08.07 A 9000/720 2001133857
Hi Thanks for all the replies on my question concerning adjustable
arrays.

They all basically told me that the compiler was right because
adjustable arrays will only work if the array with its size are sent
as a parameter. i.e.

	   integer siz
	   parameter (siz=100)
	   real arr(siz)
	   call adj_arrays(arr,siz)
	   ..
	   ..
	   subroutine adj_arrays(arr,siz)
	   integer siz
	   parameter (siz=100)
	   real arr(siz)

In the hp manual page 2-31 it has a paragraph titled "Dynamic Arrays"
it says quote 
	"An array that is a nonstatic local variable is called a dynamic
	array. For a dynamic array sorage is allocated by the current
	subprogram dynamically on the stack. This dynamic array feature is
	an HP extension to the ANSI 77 standard..."

	then it gives the example


      program main
	  i=10
	  call routine (i)
	  end

	  subroutine routine (i)
	  integer dyn_array(i)
	  dyn_array(i)=i
	  end

I tried this, it produced
eg.f:
   MAIN main:
   routine:
Declaration error on/above line 10 of eg.f;  for dyn_array; adjustable dimension on non-argument

f77: Error.  No assembly.
f77: Errors detected, no link

Which is what you'd expect for standard F77, so i tried 
$STANDARD_LEVEL SYSTEM
      program main
	  i=10
	  call routine (i)
	  end

	  subroutine routine (i)
	  integer dyn_array(i)
	  dyn_array(i)=i
	  end

$STANDARD_LEVEL SYSTEM - is a compiler option page 7-71 
	"indicates Fortran 77 plus additional system dependent features
	added to the language."

i get
eg.f:
Warning on line 1 of eg.f: unknown inline compiler option
   MAIN main:
   routine:
Declaration error on/above line 10 of eg.f;  for dyn_array; adjustable dimension on non-argument

f77: Error.  No assembly.
f77: Errors detected, no link

So I guess thats my problem. The compiler on our system
HP-UX giaec A.08.07 A 9000/720 2001133857
doesn't know the compiler directive.

Thanks again for all those that helped.
Possibly the only people that could unravel this problem is HP.

Newsgroups: comp.lang.fortran
From: rroman@casbah.acns.nwu.edu (Randall Roman)
Subject: Using C routines in Fortran programs
Organization: Northwestern University, Evanston Illinois.
Date: Fri, 31 Jul 1992 19:56:51 GMT

Is it possible to use C routines in Fortran programs and vice-versa?
I have some routines for text-processing written in C that I wish
to be used by fortran programs.  Similarly, there are fortran routines
I wish to use in C programs.  Is there a way to do this without
converting the code from one language to the other, specifically,
is there a way to use the various libraries from one language in 
programs for the other.  The environment I'm programming in is
Sparc II running Sunos 4.1.1.

--
Randy Roman
r-roman@nwu.edu
                   Jarvis needs Help!!!
From: delepine@felix-e.crihan.fr (Ludovic Delepine)
Newsgroups: comp.lang.fortran
Subject: UNFORMATTED I/O in FORMATTED FILES
Date: 22 Jul 92 13:16:43 GMT
Organization: CRIHAN, France



is it possible to use unformatted I/O with a file that has been opened in
formatted mode (standard I/O) ? 
I have tried with different compilers on different computers (IBM RS/6000, Silicon
Graphics 4D/210, ...) but sometimes it works and sometimes it fails.

                                                     LUDO.

                                     (Universite de ROUEN)
                    (Rouen Institute of Technology,FRANCE)
From: maine@altair.dfrf.nasa.gov (Richard Maine)
Newsgroups: comp.lang.fortran
Subject: Re: peculiar formatted read problem
Date: 30 Jul 92 19:30:53 GMT
Organization: NASA Dryden, Edwards, Cal.

On Thu, 30 Jul 1992 18:41:23 GMT, ejh@khonshu.colorado.edu (Edward J. Hartnett) said:

Edward> I read in new values for ddata_dir and dfilein. The above
Edward> works fine.  But, if I use default format for the first read
Edward> (i.e. * instead of '(a80)') I get no error, no end of file,
Edward> but the old value of ddata_dir is retained, even though there
Edward> is a new value in the defaults file. Furthermore, dfilein IS
Edward> read correctly from the file. So how can it skip over the
Edward> first record, without either having an error (in which case it
Edward> would go to line 3 and not read in dfilein), or reading in the
Edward> ddata_dir which is in the defaults file?

Edward> Just on trial and error, and in desperation, I changed the
Edward> format to '(a80)' and now it works great. But I don't need a
Edward> format of '(a20)' for fnamein, why?

This is one of my "favorite" careless mistakes to make with
list-directed input in my own code.  (Well, it counts as careless for
me because I know better - I just forget about it on occasion).

There must be others besides the two of us that run into this, so
I'm posting my reply instead of e-mailing.  I haven't seen this
particular tidbit posted before.

The character "/" terminates list directed input in exactly the manner
you describe.  Any further values in the input list are left unchanged.
The next read starts on the following record.  This makes list-directed
input annoying for unix path names.  There are two solutions:

1. Put the data-dir name in quotes.  This requires no code changes,
   but results in innumerable questions from the users.

2. Use "a" format as you did.  By the way, you can just use "(a)";
   you don't need to specify the 80 field width.

--
--
Richard Maine
maine@altair.dfrf.nasa.gov
Newsgroups: comp.lang.fortran