Unformatted I/O FTN95 vs Fortran77

I am trying to make sense of a program written in Fortran 77 (or earlier) that uses a series of unformatted write statements to write mixed integer and real data to an output file. A second program reads that data and uses DOS graphics to display the results in a series of charts. I have the source code for the first program, and have compiled and run it using FTN95 personal edition. The second program uses mixed Fortran and C subroutines (Fortran routine to read the data and C routines to process/display it), which I have not been able to sucessfully create an executable yet. When I try to process the data output file with the old executable file provided with the source code, it bombs with no messages. A memory dump comparision of my output file with an old sample output file shows different mapping? of the data.

Example (first 2 write statements): WRITE (N60) NBODY,NCS,IBMX,IBMN,NRW,IMN,NMN,S,REFLGT WRITE (N60) (NELM(I),I=1,NBODY) New output: 24 04 00 00 00 01 00 00 00 04 00 00 00 01 00 00 00 05 00 00 00 00 00 00 00 02 00 00 00 82 DE 8B 3D EB AB AA 3D 24 10 22 00 00 00 22 00 00 00 22 Old output: 24 00 00 00 04 00 00 00 01 00 00 00 04 00 00 00 01 00 00 00 05 00 00 00 00 00 00 00 02 00 00 00 82 DE 8B 3D EB AB AA 3D 24 00 00 00 10 00 00 00 22 00 00 00 22 00 00 00 22 00 00 00 2200 00 00

The decimal values are: nbody = 4, NCS = 1, IBMX = 4, IBMN = 1, NRW = 5, IMN = 0, NMN = 2, S = 0.068295, REFLGT = 0.083330 NELM=34,34,34,34

I assume that the hex 24 10 (hex 24 00 00 00 10) are record separators in the old and new outputs.

My question is: Is there any compiler setting(s) that will restore the output to the old format without requiring me to change the program code? I am working with another guy on this and need to avoid changing the code if I can so we can get a valid baseline. Eventually, we will rewrite all of it in C++ or C#, but not yet.

I am doing this as an interesting exercise, because I haven't used Fortran since about 1985.

Thanks for any insight

Tom

Tom

Unformatted output is compiler dependent so if the old output is produced by a different compiler, one would not expect the results to be exactly the same. In this case one can see that the results are similar with different padding. I guess the output will begin with the length of the record. The first record has length 0x24 bytes and the second 0x10 bytes. The new output does not look right because I would expect the record length to be stored as in 32 bits but I would have to run a simple test to confirm this. Also one of the 34s (0x22) is missing from the end of the new output.

The answer to your question is no. There are no settings that you can change. The record header will be compiler dependent and the way the data is presented may also be compiler dependent.

However, you can at least ensure that the two versions use the same size of integers and reals (i.e. the same number of bits for integers and the same precision for reals).

I assume that you have no choice concerning the use of unformatted output. If the output were formatted then this problem would not arise.

Paul, Thanks. I was afraid that was the case, but hoping I could get a work-around. The graphics routine, as written, is dependent on the unformatted output from the first (computation) routine.

The hex outputs I showed are the first lines that display when I 'run debug' on the two output files. I was lazy and only typed in a few lines. If you are interested, I've posted a screen shot of the two files at http://www.geocities.com/povertycrk/pictures/crig2w_crig2tst.jpg. I presume that the first hex 24 is the previous disk sector address. It's been a long time, but I seem to remember that the first two bytes are the return address and the last two bytes are the address of the next sector, or something like that.

That said, it seems that my 'new' FTN95 output, crig2w.plt displays an INTEGER*4 value for nbody as '04 00 00 00' while the 'old' output, crig2tst.plt shows it as '00 00 00 04', which is what I would expect.

Do you konw if there is any reference that explains the format of the memory dump?

Tom

Tom

Each record (i.e. each WRITE statement) begins and ends with the record size in one byte, in this case 0x24 (36 bytes for 7x4 byte integers and 2x4 bytes single precision reals, then 0x10 (16 bytes for 4x4 byte integers). The size is followed by the values in binary form each occupying 4 bytes.