| I think I remember hearing something about Oracle having a lot of
names (some of which probably clash with VMS's reserved words).
But there are many other things about Oracle which can motivate
you and your customer and the sales representative to learn more
about the virtues of VAX Rdb/VMS and the many reasons beneficial
to all for choosing the best relational database on the VAX for
the VAX.
Do the above-mentionied folks a favor and look through this conference
a little. Try dir/tit="oracle". You'll find a lot of good stuff to
help you help your customer.
Just a few things, some of which you've probably heard before:
For your customer:
Oracle is made to run on myriad hardware platforms and, due to
the "least common denominator factor," can't fully take advantage
of any one hardware/software architecture.
Rdb has a pricing structure which makes it easy for your customer,
if he's an MIS Director, for example, to fit it into his budget.
He can, for example, buy an Rdb Full Development Option license for a
MicroVAX, on which he can develop his applications, and get a Run
Time Only license for his (probably larger) production VAXes.
Oracle can be very expensive. The five year cost-of-ownership
differences between an Rdb (and tools) application and one developed
with Oracle can be large indeed. Encourage your customer to go
through the exercise of determining what the costs might be.
Oracle's latest version doesn't take advantage of the high
availability provided by VAXclusters, or the SMP architecture of
your and my favorite hardware platform.
Oracle is not integrated with the VMS operating system and the
many other Digtal products and tools with which your customer might
be familiar.
For your sales team:
Much of Oracle's revenue comes from consulting, which your team
will correspondingly loose.
An Oracle-on-Sequent solution is less expensive than an Oracle-on-
VAX solution. The Oracle rep can't wait to tell your customer all
about it.
Also, look in nova::pm01:[booth.public] for some excellent up-to-date
information that will help you.
� Anyway, one of my customers who I am told is in the final decesion stages
� of buying into ORACLE (for some undisclosed reasons)
Put on your best consultative face and ask your customer to share
with you what his reasons are. The answers may be enlightening
and help you enlighten him and get the sale.
Keep us posted here, and let us know how you're doing.
Bruce
|
| and ask if they plan to use the Language Sensitive editor to assist in
the development of the 'C' code. If so, they can use it with VAX SQL
also....if it's Oracle's SQL, forget it....
Good luck,
Gil
|
| During our V6 benchmark in Sept 89, we encountered quite a few problems
with the install and mandatory link of Oracle. On their distribution
tape, Oracle supplies a copy of the VAX C runtime library
(ORACTRL.EXE). Per the Oracle VMS install guide:
"... this file [ORACRTL.EXE] contains a copy of the VMS C runtime
library distributed by Oracle Corporation. This copy is slightly
different from the DEC version of this library, VAXCRTL.EXE, that
already resides on your system in SYS$LIBRARY. If used, ORACRTL.EXE is
linked as a shared image to ORACLE.EXE when you install the Oracle
RDBMS. You may use Oracle's copy of this library, or you may link
ORACLE.EXE to VAXCRTL.EXE, but you must link to one of these runtime
libraryies to produce the executable Oracle code."
When we tried to link to the VAXC library we got error on routines
DOPRINT and MALLOC. It seems that VMS 5.2 changed the names of these
routines to something else so Oracle wouldn't link. I can't remember
the exact sequence of events but it seems like we extracted these two
routines from the ORACRTL.EXE and inserted them into the VAXCRTL.EXE
...or... we may have link to the ORACRTL.EXE and not attempted to link
to the VAXCRTL version at all.
In either event, it seems to work OK but left me with an uneasy feeling
about that versions of the modules in the ORACRTL library.
-- gerry
|
|
As a part of a system sale at my Oracle customer, we provided software
services to convert the HP Unix C code to VAX C and decided to use
Oracle's C precompiler. (All other code at this customer site is Cobol
and makes direct calls to Oracle or passes dynamic SQL.) This
particular SWS person is one of our very best people and an excellent
C developer. In short, he ran into some significant problems with the
Oracle C precompiler and his report to me follows.
Since I don't know C, hopefully it will have more meaning to the
masses.
-- gerry
[... begin of email ...]
Subject: Oracle Pro*C problem descriptions you asked for
The problems that we encountered at xxxxxx were not major yet I had
never run into them when using a precompiler for Rdb.
The Oracle Pro*C precompiler does not appear to precompile
C's #define statements. This makes it rather difficult to define
a constant which specifies the current size of a relation element
(a table column in Oracle terms). For example --
EXEC BEGIN DECLARE SECTION
VARCHAR Test_identifier[K_TEST_ID_SIZE];
VARCHAR Result[K_WELL_MAXIMUM][K_RESULT_SIZE];
.
.
.
EXEC END DECLARE SECTION
Where K_TEST_ID_SIZE might be #defined to say 10.
In the code for xxxxxx we were forced to use a literal values
("hard code") as in the following example.
EXEC BEGIN DECLARE SECTION
VARCHAR Test_identifier[10];
VARCHAR Result[96][10];
.
.
.
EXEC END DECLARE SECTION
If Oracle provided a "CDD" for source code inclusion of table
structures into a routine, the above situation would not have
been as much of a problem.
[... end of email...]
|