Re: Urgent: Ada, Pro*Ada and Oracle 7.3.2

eachus_at_spectre.mitre.org (Robert I. Eachus) wrote:
>
> In article <330DF7A3.74F7_at_qewrf.ca> All <sdf_at_qewrf.ca> writes:
>
> > Here's the complete environment:
> >
> > Compiler: Rational Apex Ada 2.0.8
> > Precompiler: Pro*Ada 2.2
> > DBMS: Oracle 7.3.2
> >
> > I am interested in any information available that will help me embed
> > SQL in Ada using the tools listed above. I've tried searching the
> > DejaNews archive with no success. Hopefully, there are some unpublished
> > success stories out there somewhere.
>
> I have successfully used Pro*Ada with SunAda and Oracle 7.2.2, but
>I haven't tried 7.3.2 yet. I suspect that the lack of stories is due
>to the lack of Pro*Ada related problems--all my problems have been
>with configuration details, and not specific to any interface used.
>(This is not a criticism of Oracle incidently. Getting anything that
>accesses a database as a cgi-bin program configured correctly is a
>pain. You want to limit access to the minimum needed for the
>application, and on Unix creating a restricted environment is painful.
>Fortunately it is a pain once per host configuration not once per
>cgi-bin program.)
>
>--
>
> Robert I. Eachus
>
>with Standard_Disclaimer;
>use Standard_Disclaimer;
>function Message (Text: in Clever_Ideas) return Better_Ideas is...

-- 

As I can't see the original posting, due no doubt to the desire of our system admin
people wishing to keep within modest disk space requirements, I have put this here
in the hope that the originator of the plea for help spots it.

I have previously had a go at porting the Pro*Ada libraries from SunAda 1.1 (which is
actually a Verdix Ada compiler - VADS) to Rational Apex. What you have to do is not
trivial!! You have to make the Ada bindings for Rational Apex produce data structures
that mimic those produced by VADS!!

To do this you have to firstly get all the VADS Pro*Ada source files to compile into a 
Rational Apex library. This requires taking a look at the proada.mk make file, in
particular the bit that compiles the source files for VADS into the Ada library.
The proada.mk file has a line something like 'ADASRC = file file file .....' which
gives the subset of source files needed for compilation.

These files won't, of couse compile under Apex without being edited substantially, as
types defined in package standard on VADS simply aren't there in Apex, in particular
standard.tiny_integer. You will find that you need to edit package oracle's osd package
to pick up alternatives from within the subsystems supplied with Apex. Check out the
manual pages for VADS compatibility (Apex uses a VADS-next-generation backend). To
get at these alternative packages you will have to import some or all of the following
Apex supplied subsystems into your Apex library (I can't remember which - sorry)

    - lrm.ss
    - predefined.ss
    - rts_interface.ss
    - vads.ss
    - vads_compatibility.ss

There are loads of function bodies at the back of package osd that will also require editing
to match the new type definitions you introduced.

Then, if I remember correctly, you will find a good number of of 'pragma interface'
definitions that you will have to change, mainly in package oracle_c_upi. 

You have to put the name of the C program into double quotes and lowercase, and also have
to change to using pragma interface_name (again I can't quite remember),
check out the manual pages again here. You have to use whichever form provides the ability
to specify that parameters MUST be passed by reference, and have to add to the pragma
definition to ensure that this is so.

Finally, the tricky part, both to do and to describe.

You have to use the VADS compiler to find out the size and position of the components of
the record types defined in package osd. I found that VADS does not place each component
of some records contigously, and appears to introduce 'gaps', whereas Apex places them
contigously.

Then you go back to your Apex Pro*Ada copy of the source, and introduce 'dummy' record
components (an appropriately sized string) to position the 'real' record components to
the correct positions. After all, the C bodies expect the incoming data structures to
have been created by VADS. This is definitely needed for the discriminated record types
that end with an array whose bounds are determined by the discriminant!!
(You should have HOURS of fun there).

I'd like to be able to give you a more accurate account of what to do, but unfortunately
a person or persons unknown made off with the machine one night, and it turns out that
the filesystem partition I had been using wasn't covered by the nightly backup. By the
time we'd got the machine replaced the need had disappeared. So that was that - three
weeks work gone up the swanee. Also, whilst I'm fairly sure that I got it all working,
I can't be certain because we never had the opportunity to try and read the data files
we created using the 'Apex' version of Pro*Ada for VADS.

By the way, I'm not sure what Oracle's view on all this is, but I did tell them here
in the UK (oh yes I did lads) what I was attempting to do since they didn't provide
a pucca Pro*Ada tool for the job.

Hope that gets you started on the right track.

Good luck!


+================================+=====================+
| Tony Matthews                  | Senior S/W Engineer |
|                                |     GEC-Marconi S3I |
| Tel: +44 (0) 1633 835110       |         Ty-Coch Way |
|                                |             Cwmbran |
| Fax: +44 (0) 1633 835022       |               Gwent |
|                                |            NP44 7XX |
| E-Mail: tony.matthews_at_gecm.com |                  UK |
+================================+=====================+