Convert REAL*8 Unformatted Sequential file

[Intel_C_Intel]

Hi,
I am working on porting a Fortran program from a VAX/780 to PC.
The program needs to read data from an Unformatted Sequential file
as follows:

IMPLICIT REAL*8(A-H,O-Z)
DIMENSION R(4,80,6,38)
...
OPEN (UNIT=11, ERR=998, STATUS='OLD',
+ ACCESS='SEQUENTIAL', FORM='UNFORMATTED',
+ IOSTAT=IERRA, FILE='PIPEF')
READ(UNIT=11, IOSTAT=IERRA) R
...

The easiest way may be writing a snippet to convert the binary file
to a text file on the VAX, and then convert back on PC. But that VAX
box was thrown away years ago.

Does anyone know how VAX Fortran write REAL*8 type in
so-called 'UNFORMATTED SEQUENTIAL' way?

Thanks,

Gao

[Steven_L_Intel1]

See this Knowledge Base article for helpful information. The key is - how did you get the file to the PC? If the RMS record lengths from the VAX were not preserved, it will be more difficult to reconstruct the file, though not impossible since you know all the records were the same length.

Steve

[Intel_C_Intel]

I tried similiar conversions myself. You can read and rewrite bits of "direct" unformatted files. But, the sequential files has either 4* or 8* words at the front and back of each i/o access. I was never able to decipher it. If the files is small you can convert it to ascii on another machine then edit out the leading and trailing data bits.

Rudy

[Steven_L_Intel1]

OpenVMS (VAX) unformatted files, by default, are "SEGMENTED" - a complete "Fortran record" is comprised of one or more physical records, each of which has a two-byte length (maintained by the file system, not part of the data), and a two-byte flag word that indicates whether the segment is first, last, middle or both. If you manage to transfer the file preserving the record lengths, CVF can read it if you open it RECORDTYPE='SEGMENTED'. But the usual ways of copying the file, eg. FTP, drop the record lengths on the floor.

Gao is in luck, though, because all of the records (I presume) are of the same length. Therefore, you can write a program that uses FORM='BINARY' to skip the flag word, read and transfer the data. One will need to use CONVERT='VAXD' as well.

There are no "4 or 8 words at the front and back of each access". The CVF default is a 32-bit (4-byte) length at the beginning and end - as documented. VAX Fortran never writes files in this format.

The OpenVMS 'SEGMENTED' format is documented in the Compaq Fortran User Manual for OpenVMS Alpha Systems (in this case, it's the same as VAX), available on our web site.

Steve

[Intel_C_Intel]

Thanks a lot for the replys.

After examining tha binary data, I found there are no length bytes. There are flag bytes but their positions are tricky.

There is a kind of pattern in the data: 'XX 40' and 'XX 3F' and the like repeat frequently. I suppose they are the exponent part of a double.

'01 00' are the first two bytes as expected. After writing 2040 or 2048 bytes, the VAX write 2 more bytes. They are not alaways '00 00' as documented, although '00 00' appears in bytes nearby.

What is the byte order for the VAX machine?

What is the binary presentation of double 1.5 (D-format)?

It is HEX C0 40 00 00 00 00 00 00
or HEX 00 00 00 00 00 00 C0 40
or other format?

Gao

[Intel_C_Intel]

Finally, I got it.

The VAX fortran write to disk in 2k buffer (2048 bytes in my case). After 4-byte length indicators were dropped, 2044 bytes were left. What need to do is to filter out those first 2-byte flags and get a pure binary file storing double values.

The next thing is to convert VAX D_Format to IEEE double floating format. Hmmm, maybe I can sacrifice some accuracy and just do a float-to-float conversion.

Thanks a lot for clues that help me find a way to restore those legacy data.

Gao

[Steven_L_Intel1]

VAX is little-endian, like the PC.

The flag bytes won't always be 0000, and aren't documented as such. They can be 00 00, 00 01, 00 02 or 00 03 (rightmost byte is least significant).

VAX doubles are in a strange format. The lowest addressed 16-bit word contains the sign, exponent (8 bits) and 7 high-order fraction bits (most significant bit is always 1 and is "hidden".) Subsequently higher addressed 16-bit words contain the succeeding LOWER-order 16 fraction bits.

The datatype has nothing to do with the way records are written. The reason for the "segmented" records is that, until recently, OpenVMS couldn't write records that were longer than 32767 bytes. So a Fortran record, which could be longer, had to be split up into multiple records. See the documentation.

Steve