or

       real*4 rval(10)
       read(iun, *) rval

       Either of these will work as long as there is a decimal point in each
field of the input file.  The values in the input file may be separated by
commas, spaces, or tabs.

Say that your data is in a file with 6 numeric data elements per line,
such as:

1.0, 3, 10.5, 6, 11.3, 8
2.0, 4, 12.6, 7, 13.7, 112
etc.

Then you can read the data as follows:

      PROGRAM RDATA
      IMPLICIT NONE

      INTEGER IUNIT
      INTEGER IOERR
      INTEGER I

      REAL A(6)

      IUNIT = 20

     OPEN (IUNIT, FILE='filename',IOSTAT=IOERR)
     IF ( IOERR .NE. 0 ) THEN
         WRITE (*,*) 'Input file not opened'
          STOP
      ENDIF

   10 READ (IUNIT,*,END=999) (A(I),I=1,6)

*   Do what you need to do with the data:

     GOTO 10

  999 WRITE (*,*) 'End of data file'

*  Do what you need when all of the data has been read in:

      STOP
      END

  --

Custom Solutions              http://www.cs-software.com/
7638 Oldridge Road
Charleston, SC  29418          Your source for discounted
Voice:  (803) 760 0597           Fortran compilers and
Fax:    (803) 552 3239             related software

1. The decimal point is not needed, e.g. 10 or 10.0 will give the same value
for a real item.
2. A decimal point is not allowed in an integer item.
3. End of record will also be treated as a separator if the list contains
more items, thus more than one record can be read with one read statement.
4. The use of tabs is not covered by the standard, thus system dependent.
But most (all?) systems convert them to blank(s).

Greetings,
Kurt

 [about list-directed input]

I read once somewhere (probably in the UNIX HATER'S HANDBOOK) that it
was just an oversight to have tabs in make files, but this was not
changed due to backwards compatibility.  At the time, make had about 5
users.

--

Nuffield Radio Astronomy Laboratories   Tel. ..... +44 1477 571 321 (ext. 297)
Jodrell Bank                            Fax ................. +44 1477 571 618
Macclesfield                            Telex ................. 36149 JODREL G
UK-Cheshire SK11 9DL                    Web .... http://www.jb.man.ac.uk/~pjh/

Ideally, though, vendors of Fortran source code will attempt to use
a format that is transformed to standard-conforming Fortran by all,
or at least most, of the Fortran compilers still in use.  That means
using only spaces, only upper case (probably the first thing to "go"
if they want to relax a bit), not using backslashes, etc.

If you want to write code in a source-file format that is as "close"
to what the FORTRAN 77 standard mandates as possible, you have to use
all upper case, no backslashes, no pound signs, etc., and make
each and every line exactly 72 characters long, including trailing
spaces where necessary!

And, even then, whatever your operating system uses to break
lines (newline character, record delimiters, etc.) ensures that
the source file is not, in fact, standard-conforming.

That's because the standard leaves the method by which an
implementation transforms source files for use as Fortran
programs up to that implementation.

Therefore, there *is* no such thing as a source file on any
computer system that is a FORTRAN-77-standard-conforming file,
since each Fortran implementation (compiler) gets to decide
how to transform a computer systems' file into Fortran source
lines and such.

I don't think this has changed for F90 or F95, offhand.  Though,
I think it's safe to say F90's free form is much easier to
write "agreeable" source files for, in that most any implementation
will accept it (that is, its method of transformation will likely
result in a program that is not blatanly non-standard-conforming).

In the fixed-form, F77 world, most compilers' methods of
transformations include automatically breaking up visually
distinct lines, e.g. newlines, into distinct Fortran source
lines; padding short lines with spaces (though, e.g., Digital
Fortran does not do this by default, IIRC); perhaps a bit
less widely done, converting lower-case to upper-case except
in character/hollerith constants; and converting initial tabs
to either 5 or 6 spaces, depending on whether the immediately
following character is a digit (5) or not (6).  But some
convert other tabs to the tab character, which can find its
way into character/hollerith constants as such; some convert
*all* tabs into the number of spaces needed to get to the
next modulo-8 tab stop, and recognize the resulting line
beginning with a digit in, effectively, column 9 as a
non-standard continuation line; and so on.  The differences
are important when it comes to getting near the column-72
boundary and forming character/hollerith constants.  Even how
compilers handle carriage-return, aka \r, aka ^M, differs; I
think f2c puts it into character/hollerith constants as such,
while IIRC g77 just ignores it entirely.

The free-form world has fewer of these "warts", in that it
doesn't have as many sensitivities to column placement, leading
blanks/spaces, etc.

However, even in the free-form world, precisely how a compiler
chooses to transform tabs, carriage returns, backslashes, and
so on, can affect the degree to which source files using these
characters are portable.  For example, in free form, a processor
probably could safely replace tabs with *single* spaces in its
transformation process, instead of up to eight; choose to replace
carriage returns with a single space instead of ignoring them;
choose to replace `\\' with a single backslash instead of two;
and so on.

The result is that source files with lines coming near the
132-column boundary limit in free-form source can be sensitive
to such differences.

And, yet, nothing I've described above inherently makes either
the source files, or the implementations, non-standard-conforming!

--

Nuffield Radio Astronomy Laboratories   Tel. ..... +44 1477 571 321 (ext. 297)
Jodrell Bank                            Fax ................. +44 1477 571 618
Macclesfield                            Telex ................. 36149 JODREL G
UK-Cheshire SK11 9DL                    Web .... http://www.jb.man.ac.uk/~pjh/