Sequential_IO Data Portability

Sequential_IO Data Portability

[Nick Roberts]

A question was asked in GNAT chat recently as to (I hope I paraphrase
closely enough) whether, in general, the data written, via Sequential_IO, by
a brand of Ada compiler for one machine/OS target can be expected to be read
by a program, using the same type and Sequential_IO, compiled by the same
brand of compiler, but for a different target.

I would suggest that the general answer to the question must be 'no', but
that it will be 'yes' in most practical cases. In particular, I would expect
most sensible (professional?) compilers to include no 'dope' in a file
written by Sequential_IO for a type that is definite.

I would suggest that all compilers should include in their documentation the
exact format and meaning of all 'dope' (hidden) data in all I/O facilities
it comes with (I think RM95 M(69) implies this, but only very vaguely, and
Annex M is not normative). Some effort to standardise on this dope data
might also be worthwhile, perhaps?

I think the next Ada revision should make an effort to enforce a level of
documentation. Of course no automated tests could be used to verify this,
but human-level verification is perfectly practical. I'm not advocating a
densely beaurocratic approach.

--
Nick Roberts
http://www.adapower.com/lab/adaos

Re: Sequential_IO Data Portability

[Robert A Duff]

"Nick Roberts" <nickroberts@callnetuk.com> writes:

> ... (I think RM95 M(69) implies this, but only very vaguely, and
> Annex M is not normative).

Annex M is not itself normative, but everything in Annex M refers to a
normative paragraph somewhere else in the RM.  If you want to see the
real (normative) documentation rules, follow those references.

> I think the next Ada revision should make an effort to enforce a level of
> documentation. ...

IMHO, that's not a good idea.  You can't legislate good documentation.
And trying to do so leads to all kinds of nonsense.  For example, it
leads to vendors thinking they've got good documentation when all
they've done is barely obey some minimal rules.

Ada 95 already goes too far in that direction.  It's a complete waste,
because the validation process doesn't bother to check the rules.

>... Of course no automated tests could be used to verify this,
> but human-level verification is perfectly practical. I'm not advocating a
> densely beaurocratic approach.

I think the right approach is "human-level verification", as you say,
but then for those humans to gripe at their vendors if the documentation
doesn't meet their needs.  The language standards bodies and validation
bodies shouldn't get involved in this issue.

- Bob

Re: Sequential_IO Data Portability

[Thierry Lelegard]

> A question was asked in GNAT chat recently as to (I hope I paraphrase
> closely enough) whether, in general, the data written, via Sequential_IO, by
> a brand of Ada compiler for one machine/OS target can be expected to be read
> by a program, using the same type and Sequential_IO, compiled by the same
> brand of compiler, but for a different target.

This issue does not only depend on the compiler. It also depends on the
target OS and/or file-system. On OS with a "primitive" implementation
of files, a file is simply an unstructured stream of bytes. This includes
all variants of UNIX and Windows (OK, this a large part of the computer
base). However, on some other OS, a file is a structured set of records.
In that case, Sequential_IO files are likely to be implemented as one
file record for one Sequential_IO Put operation. In that case, pushing
such a file on UNIX using a binary FTP will result in a file which contains
many "metadata" from the source OS which are interpreted as data on UNIX.
They are valid files for UNIX, but invalid for the compiler.
On the contrary, pushing a UNIX file on the other OS will give an invalid
file for the OS. One example of such an OS is OpenVMS (although OpenVMS
also allows unstructured low-level binary I/O on files).

-Thierry
__________________<< WARNING: NEW ADDRESS AND TELEPHONE >>__________________

Thierry Lelegard, "The Jazzing Troll", Email: thierry.lelegard@canal-plus.fr
CANAL+ Technologies, 34 place Raoul Dautry, 75516 Paris Cedex 15, France
Tel: +33 1 71 71 54 30   Fax: +33 1 71 71 52 08   Mobile: +33 6 03 00 65 75
____________________________________________________________________________

Re: Sequential_IO Data Portability

[Tony Matthews]

Nick Roberts wrote:
> 
> A question was asked in GNAT chat recently as to (I hope I paraphrase
> closely enough) whether, in general, the data written, via Sequential_IO, by
> a brand of Ada compiler for one machine/OS target can be expected to be read
> by a program, using the same type and Sequential_IO, compiled by the same
> brand of compiler, but for a different target.
> 

The question raiser was me, so I think a little explananation might be useful
to anyone out there who might be interested.

The project I work on comprises several sub-systems, one of which is an air
traffic control simulator, and another is the exercise preparation system for the simulator.

The ex-prep sub-system comprises several workstations and a server running an Oracle RDBMS,
all running on SCO OpenServer Unix.

The simulator comprises a large number of workstations and servers, all running LynxOs Unix.

We use Alsys Ada '83 and Oracle's ProAda precompiler tool to extract the exercise data from
the ex-prep database and write out a large number (100's) of sequential_io data files which can
then be transferred via LAN over to the simulator, where they are read when the supervisor chooses
to load and run the respective exercise.

Sequential_io files are used because they minimise the data file sizes, they enable fastest loading
times on the simulator (once transferred!), and provide independent operation of the sub-systems.

We get away with this because we use the same version Alsys Ada compiler on both sub-systems, and we
don't even need to use rep specs!

However - Alsys Ada '83 (AdaWorld) is now getting a bit long in the tooth, and some of the other Oracle
based tools we use on the ex-prep system are also approaching the end of their useful lives.

So - whilst considering how we might move the project onward to Ada '95, and possibly to alternative
PC based operating systems (Linux and Windows NT spring to mind here) we are constrained by our
dependence on Oracle and sequential_io portability.

Being able to use another compiler (ie GNAT95) in the same manner without having to expend vast amounts
of effort on translating or rep spec'ing file formats (which would be tedious and error prone) means we
could concentrate our resources on system improvements.

So that's the background. If anyone has any practical experience (positive or negative) of sharing binary
files between Linux, LynxOs, SCO and/or Windows NT using GNAT95 I would be delighted to hear from you.

In his GNAT Chat mailing list response, David C Hoos kindly pointed me at the GLADE source code
(as in Ada95 RM Annex E - Distributed Systems, not the Glade GUI Builder that is associated with the
GTKAda graphical toolkit), which uses Ada.Streams. Thanks David - I will try and follow up your lead
as soon as I can.

Thanks to all respondents.

Re: Sequential_IO Data Portability

[Tony Matthews]

Nick Roberts wrote:
> 
> A question was asked in GNAT chat recently as to (I hope I paraphrase
> closely enough) whether, in general, the data written, via Sequential_IO, by
> a brand of Ada compiler for one machine/OS target can be expected to be read
> by a program, using the same type and Sequential_IO, compiled by the same
> brand of compiler, but for a different target.
> 

The question raiser was me, so I think a little explananation might be
useful
to anyone out there who might be interested.

The project I work on comprises several sub-systems, one of which is an
air
traffic control simulator, and another is the exercise preparation
system for the simulator.

The ex-prep sub-system comprises several workstations and a server
running an Oracle RDBMS,
all running on SCO OpenServer Unix.

The simulator comprises a large number of workstations and servers, all
running LynxOs Unix.

We use Alsys Ada '83 and Oracle's ProAda precompiler tool to extract the
exercise data from
the ex-prep database and write out a large number (100's) of
sequential_io data files which can
then be transferred via LAN over to the simulator, where they are read
when the supervisor chooses
to load and run the respective exercise.

Sequential_io files are used because they minimise the data file sizes,
they enable fastest loading
times on the simulator (once transferred!), and provide independent
operation of the sub-systems.

We get away with this because we use the same version Alsys Ada compiler
on both sub-systems, and we
don't even need to use rep specs!

However - Alsys Ada '83 (AdaWorld) is now getting a bit long in the
tooth, and some of the other Oracle
based tools we use on the ex-prep system are also approaching the end of
their useful lives.

So - whilst considering how we might move the project onward to Ada '95,
and possibly to alternative
PC based operating systems (Linux and Windows NT spring to mind here) we
are constrained by our
dependence on Oracle and sequential_io portability.

Being able to use another compiler (ie GNAT95) in the same manner
without having to expend vast amounts
of effort on translating or rep spec'ing file formats (which would be
tedious and error prone) means we
could concentrate our resources on system improvements.

So that's the background. If anyone has any practical experience
(positive or negative) of sharing binary
files between Linux, LynxOs, SCO and/or Windows NT using GNAT95 I would
be delighted to hear from you.

In his GNAT Chat mailing list response, David C Hoos kindly pointed me
at the GLADE source code
(as in Ada95 RM Annex E - Distributed Systems, not the Glade GUI Builder
that is associated with the
GTKAda graphical toolkit), which uses Ada.Streams. Thanks David - I will
try and follow up your lead
as soon as I can.

Thanks to all respondents.

Re: Sequential_IO Data Portability

[Ted Dennison]

In article <3895E8B2.AD802742@SpamJam.gecm.com>,
  Tony Matthews <tony.matthews@SpamJam.gecm.com> wrote:
>
> So that's the background. If anyone has any practical experience
(positive or negative) of sharing binary
> files between Linux, LynxOs, SCO and/or Windows NT using GNAT95 I
would be delighted to hear from you.

I managed to swing it using stream I/O attributes between NT/Gnat and
GreenHills/vxWorks. I had to examine the output of one with a hex editor
and modify what was done explicitly to match on both platforms. In this
effort I was helped by the fact that both architectures were the same
(PC). If I had to swap bytes on multibyte objects it would have been a
real pain.

This kind of thing is *not* easily extensible and obviously can't claim
any kind of portability.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Sequential_IO Data Portability

[Tony Matthews]

Jean-Pierre Rosen <rosen.adalog@wanadoo.fr> wrote in message
news:87646c$qal$1@wanadoo.fr...
> From: Tony Matthews <tony.matthews@SpamJam.gecm.com>
> > We use Alsys Ada '83 and Oracle's ProAda precompiler tool to extract the
> exercise data  [...]
>
> Just curious: I thought ProAda would work only with VADS (it certainly
> doesn't work with Gnat) ?
> ---------------------------------------------------------
>            J-P. Rosen (Rosen.Adalog@wanadoo.fr)
> Visit Adalog's web site at http://pro.wanadoo.fr/adalog
>
>

I know it works with VADS on SUNs, but on SCO OpenServer Unix, Oracle
decided
to go for the Alsys Ada compiler (luckily for us!). I have no idea how
Oracle arrived at
their decision, unless, of course, there was no decision to make (ie the
only Ada compiler
available for SCO OpenServer was Alsys).

It would seem that Oracle are dropping (have dropped?) further development
and support
for Ada precompilers, presumably due to lack of interest and take up by the
community at large.

This, of course, presents me with a different, but equally troublesome
problems.

Tony M.

Re: Sequential_IO Data Portability

[Tony Matthews]

Andy <andy@nospam.com.tj> wrote in message
news:3896E408.7790@nospam.com.tj...
> > Nick Roberts wrote:
>
> The project I work on does not share files, but we do share binary data
> (via messages) between
> a number of DEC Alpha platforms (using Rational Apex) and VME 68k
> platforms (using a Greenhills
> compiler). In the end we deceided to bite the bullet and rep spec all
> the messages (and closure
> of the all the types used in these messages).
>
> To this end we have developed a tool (written in shell scripts & Perl)
> to auto generate the rep
> specs. The rep specs are such that they are evaluated at compile time.
> Thus if a low level type
> changes, say from scalar to a physically larger/smaller scalar, or to a
> composite type, then the
> rep specs of the types dependent upon this type are automatically
> adjusted at compile time (by
> both compilers).
>
> While I cannot provide the scripts or the Perl (they are designed to
> work within an Apex
> environment anyway) I could provide more info on the compile time
> arithmetic we perform in
> order to generate the rep specs if required.
>
> (we also have to perform endian conversions, but that's another story).
>
> ___________________________________________
>
> Andy Starritt
> ___________________________________________


I didn't want to scare anyone away with too much detail, but we also pass
binary messages via LAN between
the sub-systems for the purpose of health monitoring, request/response, data
transfer etc, so the consistent binary
representation provided between sub-systems by having the same Ada compiler
is something we rely on at present,
and would be a great loss to us.

We also use Rational Apex as our development environment (Apex NT 3.0.2b
with a Solaris shadow server in fact), so
your approach is certainly a promising alternative.

However, I'm still hoping that I can avoid having to do that, use a single
compiler across both platforms, and leave it
all to the compiler!

If you have the time to e-mail me with further details, I will follow this
up with you.

Thanks.

Tony M.

Re: Sequential_IO Data Portability

[Jean-Pierre Rosen]

From: Tony Matthews <tony.matthews@SpamJam.gecm.com>
> We use Alsys Ada '83 and Oracle's ProAda precompiler tool to extract the
exercise data  [...]

Just curious: I thought ProAda would work only with VADS (it certainly
doesn't work with Gnat) ?
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Sequential_IO Data Portability

[Andy]

> Nick Roberts wrote:
 
> Being able to use another compiler (ie GNAT95) in the same manner without having to expend vast amounts
> of effort on translating or rep spec'ing file formats (which would be tedious and error prone) means we
> could concentrate our resources on system improvements.
> 
> So that's the background. If anyone has any practical experience (positive or negative) of sharing binary
> files between Linux, LynxOs, SCO and/or Windows NT using GNAT95 I would be delighted to hear from you.
> 
The project I work on does not share files, but we do share binary data
(via messages) between
a number of DEC Alpha platforms (using Rational Apex) and VME 68k
platforms (using a Greenhills
compiler). In the end we deceided to bite the bullet and rep spec all
the messages (and closure 
of the all the types used in these messages). 

To this end we have developed a tool (written in shell scripts & Perl)
to auto generate the rep 
specs. The rep specs are such that they are evaluated at compile time.
Thus if a low level type
changes, say from scalar to a physically larger/smaller scalar, or to a
composite type, then the 
rep specs of the types dependent upon this type are automatically
adjusted at compile time (by 
both compilers).

While I cannot provide the scripts or the Perl (they are designed to
work within an Apex
environment anyway) I could provide more info on the compile time
arithmetic we perform in
order to generate the rep specs if required. 

(we also have to perform endian conversions, but that's another story).
 
___________________________________________

Andy Starritt
___________________________________________