Pro*Ada

Pro*Ada

[Don Tyzuk]

Good Morning!

Does anyone out there have any experience with Oracle's
Pro*Ada?  I'm not asking for tech support, just a straw
poll of who uses it and what their impressions are.

Does it even really exist?  Readers at Oracle Corp.
are welcome to respond by e-mail or with literature.

Thanks.
--
Don Tyzuk                           |  email : don.tyzuk@acadiau.ca
Jodrey School of Computer Science   |  smail : PO Box 1406
Acadia University                   |          Wolfville NS B0P 1X0

Re: Pro*Ada

[Matthew C. Sargent]

In article <36v38v$hsg@newsbf01.news.aol.com>, wlawton@aol.com (WLawton) wrote:

> In article <1994Oct5.113638.26570@relay.acadiau.ca>,
> 841613t@dragon.acadiau.ca (Don Tyzuk) writes:
> 
> >Does anyone out there have any experience with Oracle's
> >Pro*Ada?  I'm not asking for tech support, just a straw
> >poll of who uses it and what their impressions are.
> >
> >Does it even really exist?  Readers at Oracle Corp.
> >are welcome to respond by e-mail or with literature.
> 
> I have used it, ergo, it does exist.  Essentially, Pro*Ada is a
>[snip]
> 
> 'nuf said...
> 
> Wayne R. Lawton
> various affiliations, my fingers typed this, they are on their own

I have a pretty good understanding of pro*ada. It is available for most of
the Ada compilers out there. It works, but like all pre-processors, you
lose some control of what is happening in your code. For example, after
pre-processing your code will have USE statements. Your code will also now
be two files. Both of these things can cause problems with project
standards and configuration control. There are also issues with how their
dynamic sql statements are implemented (raw addresses) that may make you
shiver, but they can be avoided by not using these features if they worry
you. 

There is also OCI (Oracle Callable Interface) in Ada if you want to go
with that interface.


Good Luck,

---------------------------------------------------------------------
|                                 |                                 |
|Matthew C. Sargent               |             |                   |
|Rational Software Corporation    |          __/ \__                |
|sarge@Rational.com               |   -=======(_*_)=======-         |
|804-491-0372                     |         |       |               |
|804-425-5859 Fax                 |         O       O               |
|                                 |                                 |
|                                 | SuperSportster40/SuperTiger40   |
|--------------------------------------------------------------------
<Place standard disclaimer here>

Re: Pro*Ada

[ERIC E. MAYS]

In article <sarge-1110942238230001@ohno.ppp.verdix.com>, sarge@Rational.Com (Matthew C. Sargent) writes:
|> In article <36v38v$hsg@newsbf01.news.aol.com>, wlawton@aol.com (WLawton) wrote:
|> 
|> > In article <1994Oct5.113638.26570@relay.acadiau.ca>,
|> > 841613t@dragon.acadiau.ca (Don Tyzuk) writes:
|> > 
|> > >Does anyone out there have any experience with Oracle's
|> > >Pro*Ada?  I'm not asking for tech support, just a straw
|> > >poll of who uses it and what their impressions are.
|> > >
|> > >Does it even really exist?  Readers at Oracle Corp.
|> > >are welcome to respond by e-mail or with literature.
|> > 
|> > I have used it, ergo, it does exist.  Essentially, Pro*Ada is a
|> >[snip]
|> > 
|> > 'nuf said...
|> > 
|> > Wayne R. Lawton
|> > various affiliations, my fingers typed this, they are on their own
|> 
|> I have a pretty good understanding of pro*ada. It is available for most of
|> the Ada compilers out there. It works, but like all pre-processors, you
|> lose some control of what is happening in your code. For example, after
|> pre-processing your code will have USE statements. Your code will also now
|> be two files. Both of these things can cause problems with project
|> standards and configuration control. There are also issues with how their
|> dynamic sql statements are implemented (raw addresses) that may make you
|> shiver, but they can be avoided by not using these features if they worry
|> you. 
|> 
|> There is also OCI (Oracle Callable Interface) in Ada if you want to go
|> with that interface.
|> 

Matthew,

    Have you tried using user-exits to call ada programs from sql*forms?

Thanks,

Eric

Re: Pro*Ada

[Maarten Landzaat]

Hi, 

I worked with Pro*Ada on VAX/VMS. I posted the following message some
time ago. I hope it will be of help to the original poster. 

---------------------------------------------------------------

From comp.databases.oracle Wed May 11 21:32:28 1994
Subject: Summary of problems with Oracle's Pro*Ada

Hi,

Here's a list of problems we encountered using Pro*ada with Oracle 7 on
VAX VMS, using DEC Ada.

Some time ago an Oracle employee wrote to me that Oracle hardly ever receives
feedback from the Ada community, and therefore he suspected the Ada community
to be a 'self-sufficient lot'. 

To change this, in the hope that it will improve the Oracle products, we
compiled a list of problems and peculiarities using Oracle with DEC Ada.

We wasted some considerable time finding causes and solutions to the following
problems. I hope that by providing this list Pro*Ada users will save time in 
the future.

If you are a Pro*Ada user, please post your experiences. We and Oracle Corp. 
will learn from it.

Pagenumbers refer to the "Programmer's Guide to the Pro*ADA Precompiler" 
version 1.5.


The list: 
------------------------------------------------------------------
About the Pro*Ada manual:

-       p. 3-38 Tasking:
        The manual suggests here that using tasks with timeslicing and Oracle
        is possible. In reality, this is NOT possible. At least not on our machine,
        where it yields Access Violation errors.

-       p. 2-10:
        The book often uses Oracle functions before they are explained. Some are
        not explained at all. Example:
        What is INITCAP?
        What is upper?

-       The new Oracle manuals smell badly. Though the format is quite handy,
        the smell really keeps me from looking up things in the manuals.
        The subjective obnoxiousness seems to vary from person to person.

-       p. 7-3 and 7-5:
        Is it:
        ORACLE_TYPES.ORACLE.TYPE or
        ORACLE_TYPES.ORACLE_TYPE?

-       p 9-10 and 9-11:
        Is it:
        EXEC SQL OPEN cursor USING DESCRIPTOR BIND_DESC;        or
        EXEC SQL OPEN cursor USING BIND DESCRIPTOR BIND_DESC; ?
        These statements are taken from example programs. This means that
        example programs have not been tested. Bad examples.



About the precompiler:

-       While there is automatic conversion from nearly all standard Oracle types
        to Ada types, there is none for the date and enumeration types.
        The implementation should be trivial.
        Oracle's DATE should be automatically converted to CALENDAR.TIME and 
        vice versa.
        Ada's enumeration types should automatically be converted to Oracle's
        NUMBER and vice versa.

-       When 'semantic checking' is activated,
        DELETE FROM <non-existent table>        is recognized as wrong, but
        INSERT foo INTO <non-existent table>    is not.
        This inconsistency makes one doubt that a precompilation without
        error messages really is successful.

-       Error messages are put in a .LIS file or sent to the terminal. It is
        difficult to correct your programs this way; you have to look up the
        line number and finding the correct line in your .PAD file. 
        Since many people use LSE, the precompiler should be able to generate
        the error messages into a diagnostics (.DIA) file when the
        /DIAGNOSTICS flag is given.
        This would also be very easy to implement.
        The precompiler should also call the Ada compiler after successful
        precompilation. If errors in the Ada compilation occur, the line numbers
        should be translated to line number in the original .PAD file.
        As a temporary solution, we wrote a utility that translates the error
        messages in a .LIS file to a .DIA file. This utility is available on
        request: send mail to gijs@mbase97.hacktic.nl.

-       Our beginner's mistake: not being logged in, was very primitively
        fed back to us by presenting the message 'Statement not parsed'.
        When we added some error-raising code in the generated code, we
        found out what was wrong. Then Oracle DOES seem to be able to
        issue a message like 'Not logged in'. 
        For the same reason, erroneous SQL statements, that were precompiled
        correctly, would yield 'statement not parsed' instead of a more
        useful message. Inserting exception-raising code would reveal the
        real cause of the statement not being parsed.

        Note that this manual insertion takes much time: precompilation and 
        compilation are quite slow on a VAX.

        The placement of error-raising code by the precompiler seems to 
        wrong, or at least not optimal.

        After a while, we changed the Oracle library unit 'ORACLE__SQL', so
        that proper error messages are generated automatically. It outputs
        the message with TEXT_IO, so it is only suitable at development time.

-       When oreclen < ireclen, we encountered the following problem when using
        long comment lines:
 
        -------------------------------
        >proada iname=prog.pad sqlcheck=semantics userid=/ ireclen=255 lreclen=255 lname=lis.lis
        Pro*Ada: Release 1.5.6.2.0 - Production on Fri Aug 13 15:35:40 1993

        Copyright (c) Oracle Corporation 1979, 1992.  All rights reserved.


        Precompiling prog.pad
        Allocated memory block has been overfilled.

        PRO* has detected an internal error (2).
        Please contact Oracle Corporation Customer Support.
        -------------------------------

        First we didn't know about the oreclen>=ireclen rule, so it took us a 
        long time to figure out what caused this message. 

        The manual states that oreclen must be set to at least the ireclen,
        but I would have preferred it if this rule were somehow built-in to the
        precompiler, so that:
        a: it could generate a USEFUL error message, or
        b: it could set oreclen itself.

-       Functions used in place of host variables only work when they have zero
        or one parameter. Something goes wrong at the comma separating the
        parameters. This also means you cannot use more-dimensional arrays
        as host-variables.
        It seems that there is no correct Ada parser in the precompiler.

-       In the following where clause:
        'WHERE STRING_COLUMN = :SOME_ADA_INTEGER'
        the STRING_COLUMN is apparently converted to an integer and subsequently 
        compared to the SOME_ADA_INTEGER. This yields a NUMBER_ERROR if the
        string does not contain a number, even though it is clear that the
        fields are not equal.
        It would be better to convert the INTEGER to a STRING, and then compare
        the fields.

-       When you forget a closing parenthesis in an embedded SQL statement,
        the preprocessor often hangs, eating much memory and CPU time.
        Another case of a strange parser.

-       From a user's point of view, I find it very strange that a bind descriptor
        must not be prefixed by a ':', even though they are declared as an
        Ada variable.

About PL/SQL:

-       A procedure declaration only worked with <CR>, <LF>, spaces and tabs
        in the right place. The 'right' places are hard to determine.
        In these days, these space characters should be interchangeable, especially
        because PL/SQL is modelled after Ada.



Conclusions:

-       A few (easily implementable) additional features and bugfixes would 
        make life a lot easier.

-       The parsers for both Ada and SQL constructs contain bugs.

-       The manual contains untested example programs, which is unacceptable.

A reaction from Oracle Corp. would be much appreciated.
-- 
Gijs Bok (gijs@mbase97.hacktic.nl)
Listen to M-BASE music!
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.3a

mQA9AiyWNO4AAAEBgNsly7W6TnOlaVLOWbrkRyw1ATzledvUhPwrtAbeO/1FVOaD
pmwtRkJoqMpnIYhwYQAFEbQiR2lqcyBCb2sgPGdpanNAbWJhc2U5Ny5oYWNrdGlj
Lm5sPg==
=J27y
-----END PGP PUBLIC KEY BLOCK----
-- 
Maarten Landzaat (gijs@mbase97.xs4all.nl)
Amsterdam, Double bass, Fender Jazz Bass, Atari ST, Roland Sound Canvas.
Listen to M-BASE music!

Re: Pro*Ada

[David Emery]

>Some time ago an Oracle employee wrote to me that Oracle hardly ever receives
>feedback from the Ada community, and therefore he suspected the Ada community
>to be a 'self-sufficient lot'. 

Without going into details, I can assure you that we've used Pro*Ada
and we've provided _substantial_ feedback to Oracle Corporation.

				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

Re: Pro*Ada

[Maarten Landzaat]

In <EMERY.94Oct18111250@goldfinger.mitre.org>, David Emery writes:
>>Some time ago an Oracle employee wrote to me that Oracle hardly ever receives
>>feedback from the Ada community, and therefore he suspected the Ada community
>>to be a 'self-sufficient lot'. 
>
>Without going into details, I can assure you that we've used Pro*Ada
>and we've provided _substantial_ feedback to Oracle Corporation.

I think it's been about ten months since I read that Oracle employee's
posting; so the remark may be out of date. 

Did you get any response from Oracle? I didn't mail my problems-list,
but posted it one Usenet only, since we already figured out workarounds.
Somehow your choice of words suggests that you weren't too happy
with the response :-)
-- 
Maarten Landzaat (gijs@mbase97.xs4all.nl)
Amsterdam, Double bass, Fender Jazz Bass, Atari ST, Roland Sound Canvas.
Listen to M-BASE music!

Re: Pro*Ada

[Richard G. Hash]

> >Some time ago an Oracle employee wrote to me that Oracle hardly ever
> >receives feedback from the Ada community, and therefore he suspected
> >the Ada community to be a 'self-sufficient lot'. 
> 
> Without going into details, I can assure you that we've used Pro*Ada
> and we've provided _substantial_ feedback to Oracle Corporation.

Well our latest beauty with Pro*Ada is that recently we tried to move
from Verdix 6.1.0(e) to Verdix 6.2.1(e) for AIX, and lo-and-behold, there
were problems...  So we called Oracle and got this reply: they *do*
support 6.2.1, but "only for the Government". If you are willing to pay
for a special support agreement then you can get it too (you can
call Carol Estridge to inquire about the cost).

In the past they have tracked new compilers releases pretty well.
Given the level of money Shell companies pour into Oracle every
year, I just couldn't believe this. Not a good sign.

--
Richard G. Hash                                      email: rgh@shell.com
Shell Development Company, Bellaire Research Center  phone: (713) 245-7311
Member Team Ada                Free Ada94 compilers: cs.nyu.edu:/pub/gnat

Re: Pro*Ada

[Thomas Hood 913-4501]

In article <rgh.783019527@camo>, Richard G. Hash <rgh@shell.com> writes:
|> > >Some time ago an Oracle employee wrote to me that Oracle hardly ever
|> > >receives feedback from the Ada community, and therefore he suspected
|> > >the Ada community to be a 'self-sufficient lot'. 
|> > 
|> > Without going into details, I can assure you that we've used Pro*Ada
|> > and we've provided _substantial_ feedback to Oracle Corporation.
|> 
|> Well our latest beauty with Pro*Ada is that recently we tried to move
|> from Verdix 6.1.0(e) to Verdix 6.2.1(e) for AIX, and lo-and-behold, there
|> were problems...  So we called Oracle and got this reply: they *do*
|> support 6.2.1, but "only for the Government". If you are willing to pay
|> for a special support agreement then you can get it too (you can
|> call Carol Estridge to inquire about the cost).

Well, I think we're "the Government" being referred to here.  They asked
us to draft a business case for supporting back levels of their
environment before they would "fix" the problem.  In their eyes, the
fact that Verdix changed how records are physically represented in
6.2.1(e) didn't constitute a bug in their (Oracle's) code.  BTW, they
considered Oracle 7.0.x to be "back levels" since 7.1.3 would be out
Real Soon Now(tm).  A few phone calls from Marketing got them straight.
The upshot is if you want Pro*Ada to work with Verdix 6.2.1(~) then
get Oracle 7.1.3 and the new version of Pro*Ada with it.

|> 
|> In the past they have tracked new compilers releases pretty well.
|> Given the level of money Shell companies pour into Oracle every
|> year, I just couldn't believe this. Not a good sign.
|> 
|> --
|> Richard G. Hash                                      email: rgh@shell.com
|> Shell Development Company, Bellaire Research Center  phone: (713) 245-7311
|> Member Team Ada                Free Ada94 compilers: cs.nyu.edu:/pub/gnat

-- 

Thomas Hood
hoodt@lfs.loral.com
-- Ada grunt since 1985
-- Member Team Ada since 1994
-- Member Team Human since 1965
--
-- My opinions are not those of my employers, and if they were I'd probably
-- reject them out of hand and form new ones.