[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::fortran

Title:Digital Fortran
Notice:Read notes 1.* for important information
Moderator:QUARK::LIONEL
Created:Thu Jun 01 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1333
Total number of notes:6734

1170.0. "Definition of unformatted VMS FORTRAN binary files?" by HYDRA::PASHAPOUR (Disk space, the final frontier) Mon Feb 10 1997 15:21

    Hi,
    
    An ISV has an urgent need to know exact definition of unformatted VMS
    FORTRAN binary files.
    
    Looking at the file, he sees two bytes that define how many words is
    written and then something at every 512 bytes.
    
    They are trying to release this post-processor application that can
    handle the UNIX created files, but have run into problem with VMS. They
    are primarily using ANSI C fopen/fseek/fwrite/fread to deal with the
    files.
    
    Is there anythis else they should watch-out for such as the file being
    FTPed?
    
    Thank you in advance.
        
    Amin
T.RTitleUserPersonal
Name		DateLines
1170.1More information will be supplied.HYDRA::PASHAPOURDisk space, the final frontierMon Feb 10 1997 15:296
    Of course, I have told him to talked to the people who write the file
    in the first place. I'll give more information, once I know more.
    
    Thanks.
    
    Amin
1170.2QUARK::LIONELFree advice is worth every centMon Feb 10 1997 16:2644
This format is documented in the user manual.

There are two layouts for unformatted files - the default on VMS is the
"Fortran SEGMENTED" type.  This is an RMS VAR (varying-length records) file
which means that for each record there is a 16-bit length followed by the data.
RMS will add a pad-byte after the data if the length is odd.  In the data,
Fortran puts two bytes of flags at the beginning.  This is the "segment control
word".  The defined values are:

	00 - this is neither the first nor the last segment in this record
	01 - this is the first segment in this record
	02 - this is the last segment in this record
	03 - this is the only segment in this record

For long Fortran records (where "long" by default is about 1024 bytes),
the Fortran record is broken up into two or more segments, each segment being
an RMS record.  Keep in mind that to RMS, the segment word is data, so the
RMS record length is two more than the length of the data part of the segment.
I'm not sure what is causing the "something at every 512 bytes" - a lot would
depend on what the RECL was.

One can also open the file with RECORDTYPE='VARYING' - this uses the RMS
VAR recordtype with no segment information, or with RECORDTYPE='FIXED' (which
is probably not an issue here.)

With either SEGMENTED or VARYING, it is critical that the file be transferred
in a way that preserves the RMS record length word.  By default, this will
be stripped off by FTP.  On VMS, UCX FTP has PUT/RAW which will just move the
blocks of data, leaving the recordlengths (and padding) alone.

Digital Fortran on Digital UNIX can read VMS SEGMENTED files *IF* the file
has been transferred "/RAW" and the file is opened with RECORDTYPE='SEGMENTED'.

If the user has control over the VMS application, and if all the records are
the same length, I would recommend that RECORDTYPE='FIXED' be used with an
appropriate RECL.  This will remove the issue of RMS record lengths.  Another
approach is to convert the VMS file to something that UNIX will like - see
http://quark.zko.dec.com/fortran/vmsvar_to_unix.for for a program that will
convert RECORDTYPE='VARIABLE' files to a UNIX Fortran "unformatted" layout
that has four-byte record lengths in the data.

If the customer needs more info, let me know.

				Steve
1170.3thanks andHYDRA::PASHAPOURDisk space, the final frontierMon Feb 10 1997 16:4810
    Thank you Steve. I will forward your note to the ISV. I think they have
    to do a little bit of work also to get around floating-point data in
    the binary file to make IEEE unix boxes understand what's in there.
    
    Your explanation is very good. I'll let you know, if I hear anything
    back.
    
    Thanks again.
    
    Amin
1170.4QUARK::LIONELFree advice is worth every centMon Feb 10 1997 16:506
Again, if they have control over the VMS application, they can make things
much easier for themselves by using CONVERT='BIG_ENDIAN' (or 'LITTLE_ENDIAN' as
appropriate).  The customer won't be able to access the URL I cited - you
can extract the file and mail it to them if they want it.

				Steve