Tricky FORTRAN -> Ada data file conversion

Tricky FORTRAN -> Ada data file conversion

[EDSKO]

A rather lengthy query follows.  Those with weak constitutions or short
attention spans should move on to the next article.

We are attempting to use Ada to read files created by FORTRAN unformatted
writes.  These records may be loosely classified as discriminated records,
but each particular variant can be variable size.  The format of a typical
variant of the record follows (in FORTRANese)

 word   variable  type       storage details
 ----   --------  ----       ---------------
 1      rtype     a8         left justified (lj), space filled (sf) in 64 bits
 2      jon       a5         lj, sf in 64-bit word
 3      itail     integer    signed binary, 64 bits
 4..13  title     10(a6)     6 chars lj, sf in 64 bits; repeated 10 times
 14     itest     integer    signed binary, 64 bits
 15     flt       a4         lj, sf in 64 bits
 16     dflt      a6         lj, sf in 64 bits
 17     dreq      a6         lj, sf in 64 bits
 18     dcom      a6         lj, sf in 64 bits
 19     n         integer    signed binary, 64 bits
20..19+n rem      n(a6)      6 chars lj, sf in 64 bits; repeated n times
 20+n   jflagp    integer    signed binary, 64 bits

An Ada-ish record definition for the above looks something like

    rtype  :  string(1..8);
    jon    :  string(1..8);
    itail  :  integer;
    title  :  string(1..80);  -- the string is peppered with intervening blanks
    itest  :  integer;
    flt    :  string(1..8);
    dflt   :  string(1..8);
    dreq   :  string(1..8);
    dcom   :  string(1..8);
    n      :  integer;
    rem    :  array(1..n) of string(1..8);  -- note n is VARIABLE, is it legal?
    jflagp :  integer;

The record is read according to the FORTRAN statement:

  READ(unit) rtype,jon,itail,(title(i),i=1,10),itest,flt,dflt,dreq,dcom,n,
 +           (rem(i),i=1,n),jflagp

The actual read is accomplished in two steps by virtue of the implied DO's.
19 words are read, n is digested, then n+1 words are read.

Question 1:  Can Ada deal with a record with a field whose size is dynamic?
             For these records, n has a known maximum value (20), but it
             does vary from record to record.

Question 2:  If Q1 has a yes answer, can Ada I/O read such a record from a file
?

As if the above weren't bad enough, the file we are reading has several record
types which are determined by the first 8 bytes (rtype).  To sequentially read
this file, we need a file of discriminated records.  If we redefine the record
as indicated below, I am certain that the compiler will abort because the
descriminator must be a scalar or subrange.

(pardon my broken Ada)

TYPE the_record(rtype: string(1..8):=default_value) IS RECORD
   CASE rtype IS
     when 'P       '
        a list of fields
     when 'FMT     '
        a different list of fields
     when '????????'  -- various known record types exist.
        an appropriate list of fields for each known record type
     OTHERWISE  -- I don't even know if Ada has a catch-all
        yet another list of fields
   end CASE;
end RECORD;

Question 3: Can the descriminator rtype be redefined as an integer, and the
            WHEN values be the integer equivalent of the character array?

Question 4: Can the descriminator rtype be redefined as an enumeration, and
            by using the FOR rtype USE clause specify the 64-bit value of the
            ASCII (e.g. for 'P       ' specify x'5020202020202020')?

Our current workaround is to define either a large string or an array of
64-bit words as one of the variant records and thus overlay the appropriate
type.  We are not yet to the point of scanning the string or array and setting
the discriminator to the appropriate value.  Using the coincidental overlaying
does not strike some of us here as adhering to the 'Ada paradigm,' but given
that FORTRAN unformatted I/O is system dependent anyways, I have no guilt
complex from kludging the silly thing.

I welcome any further clues or alternate strategies.  I do not subscribe to
Info-Ada, but others at my site do.  If you have some comments which are
not for distribution-wide consumption, please email me directly.

Ed Skochinski                 email: edsko@nosve.elan.af.mil
Control Data Systems, Inc.    phone: 805.277.3152
Edwards AFB

 Chism's Law of Completion:
      The amount of time required to complete a government project is
      precisely equal to the length of time already spent on it.