[comp.os.vms] VAX Ada and CDD

sommar@enea.se (Erland Sommarskog) (03/02/91)

This is more a less an RTFM question, but it turned out that
the customer site where I am only had the manuals for VAX
Ada 1.0 which I didn't even bother to look at. Yes, we plan
to get our own manual set for the department where I am.

What want I to do is simple. I'm accessing an RDB database,
and I do not want to redeclare the database definitions,
but fetch them from the CDD. In other DEC languages there
are directives like %DICTIONARY to do this. How do you
do this in VAX-Ada? *Can* you do it? I searched the Ada
module in the VMS HELP library, and found nothing, neither 
"CDD" nor "dict".

If it is not possible to include them directly, I can still
think of generating Ada declarations from the CDD in some
way. Anyone who already has done this and is willing to
share his efforts?

We have RDB 3.1, but will soon go to 4.0. Has the stupid
restriction that SQL$PRE does not support INCLUDE FROM
DICTIONARY for Ada disappeared in 4.0? That would suffice
to solve my problem.

Please mail answers to me personally, since I will get them
faster that way. I will summarize any interesting findings.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se

sommar@enea.se (Erland Sommarskog) (03/07/91)

Recently I asked for CDD support with VAX Ada. Yes, it is there.
There is a facility shipped with VAX Ada with which you can
generate packages, or just code fragments to paste in, from
CDD definitions.

It was pointed out to me by someone who was kind to send me 
excerpts from the help text for Ada 2.0. At the site I am, 
we have 2.1 and apparently the section on CDD_interface has 
fallen away from the help text. (And the manuals, as I told,
are dislocated.)

Whether this feature is useful or not remains to see. All I
can say this far is that DEC's SQL preprocessor makes severe
hindrances to use use Ada for modular programming with a strong
type concept.

If SQL gave a damn in doing type conversions (e.g. date => string)
it wouldn't have understand the host declarations, lifting the
requirment that all types referred to in SQL statements must be
declared in the same source file. I realize that this is probably
ANSI, but by giving the qualifier /STUPID one could take away this
feature which is questionable in the first case in an Ada-style of
programming where implicit conversions are a no-no.

Thanks to you who replied to my question.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se

brown@gcc.uucp (The Raven) (03/17/91)

In article <2757@enea.se>, sommar@enea.se (Erland Sommarskog) writes:

> can say this far is that DEC's SQL preprocessor makes severe
> hindrances to use use Ada for modular programming with a strong
> type concept.
> 
> If SQL gave a damn in doing type conversions (e.g. date => string)
> it wouldn't have understand the host declarations, lifting the
> requirment that all types referred to in SQL statements must be
> declared in the same source file. I realize that this is probably
> ANSI, but by giving the qualifier /STUPID one could take away this
> feature which is questionable in the first case in an Ada-style of
> programming where implicit conversions are a no-no.

True.  However, DEC's ada provides data type packages that allow you to
utilize all the VMS datatypes.  The SQL preprocessor, for portability
reasons doesn't utilize them - it only uses ansi data types.  If you want
to get around it, use the SQL Module Language.  In ADA, that works very
well - all you have to do is declare the package information to link the
sql module language obj file into your ACS library.  Since the latest
version of RDB/SQL provides for the declaration of record structures within
the module language for parameter passing, this method begins to look very
attractive from any language.

-- 
       +-------------------------------------------------------------+
       |   Mitchell W. Brown              Internet: brown@gcc.uucp   |
       | Grove City College TLC           Uucp: ...pitt!gcc!brown    |
       |  Grove City, PA 16127            (412) 458-2072             |
       +-------------------------------------------------------------+