Xiaogang Wang writes:
 > I found the following program 1 and 2 give different binary files.
 > Could anyone explain why?

The answers to all your questions in this post are related (as is
probably no surprise). Fortran I/O is record-oriented. The f2k
draft adds new options, and many current compilers have some
extensions in this area, but standard Fortran I/O up to f95 is
always in records. For unformatted I/O, each read or write handles
exactly one record - no more and no less. So no, you can't do
the kinds of things you are asking about (but see one hack
mentioned below).

In terms of implementation, the system has to somewhere keep track of
where the record boundaries are. That's because it has to be able to
do things like skip records (and other things, but skipping records is
the simplest example). The Fortran standard requires that capability.
If you just do a

  read(11)

with no I/O list, that just skips a record. Somewhere there needs to
be information telling the system how much to skip. For unformatted
files, this is most often done by putting record length information at
the beginning and end of the record (the copy at the end is to support
backspacing).

So if you write 2 records, you'll get those reacord headers/trailers
for both records. This isn't the same thing as you get when you write
the sam edata as a single record, and you can't read it back as though
it were a single record - it isn't.

There is one possible hack that is *NOT* guaranteed by the standard,
but can be made to work on almost all current compilers. Direct
access files are usually implemented as just the data - no record
headers/trailers. This is possible because all of the records in
a direct accessfile are required to be of the same size (which is
specified in the OPEN statement). Thus the record boundaries are
trivially computable without anything embedded in the file.

For compilers that implement direct access like this (i.e. almost
all of them), you can read a file with a different record length
than you wrote it with and the data will just appear to be organized
into records of the specified length. You could make use of that
feature to do your

 > write(11) A

and then

 > Can I read it in column by column in a different code by doing
 > read(11)A(:,1)
 > read(11)A(:,2)

though you'd need to add appropriate rec= specifiers to each of
those reads and writes.

Though that hack will almost surely work, I'd probably recommend that
you just write the array column by column if you intend to read it
that way. Then you are perfectly standard conforming, and it isn't
particularly difficult to do (probably easier than fussing with
specifying the record lengths and record numbers appropriately
for direct access).

You could also use one of the nonstandard extensions, but I'd
not recooemd that as the first choice.

--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
                             | -- Mark Twain