| > Here we are now having a keen competition with Oracle with our Rdb
> V3.0 and ACMS. We are a bit worried that the customer would choose
> ACMS and ORACLE. I know that if ORACLE has to be used with ACMS,
> the interface will be through 3GL database call.
> Can anybody tell me more about the precompiler for ORACLE,
> how does that compare with our RDBPRE ?
> Does the PROCOBOL of ORACLE behave like our callable RDO ?
If the customer is to use ACMS, then they might be interested in our
TP architecture (we have one, Oracle doesn't). The Oracle solution
requires the use of our TP monitor (ACMS) and our forms products (TDMS or FMS).
SQL*FORMS would not work with ACMS.
Oracle's precompilers require that programs be compiled without optimization
(/NOOPTIM) producing less efficient code. In addition, the Oracle precompilers
require that runtime libraries be available on the target system.
That is, any machine that wants to run an Oracle precompiled program must
install Oracle's precompilers (even for runtime systems). Oracle doesn't
have any concept of a runtime system.
I don't know what impact this will have on performance, but it could be
significant. It does have an impact on price. The precompilers will
have to be licensed on all machines running the task definitions.
Each Oracle precompiler costs $18,000 on a VAX 6240 (for example). Then
there is the cost of maintenance (7.5% for updates, 15% for phone support
per year, per license). The costs for there DBMS are even more outrageous.
If the customer wants performance, they will need to purchase Oracle's TPS
(transaction processing subsystem). It is only through this system that
you get row-level locking, online backup, etc. All these come with Rdb.
TPS costs an additional 60% of the Oracle DBMS license (again, plus 22.5%
a year in support costs).
Oracle also wants there customers to use their new language PL/SQL for
performance. This language is Ada like and is totally incompatible with
Oracle's previous SQL products. I have no idea how PL/SQL will integrate
with ACMS. Some of the same concepts are in both ACMS and PL/SQL, but
they are probably not compatible. I don't know if PL/SQL is its own
language (with compiler) or if it is precompiled and then compiled
with a VAX language.
The customer should really have a TP monitor designed to work with
the database (Rdb).
Another issue is what happens when the customer has a problem implementing
the solution. TP monitors, Forms, and databases are tightly coupled.
How can we support Oracle's database and help them in design? How can
Oracle help the customer with ACMS and TDMS?
Hope this helps. Call with questions.
--David
dtn 381-2893
|
| Here's the scoop on Oracle V5.1 interface. There are two ways to
get to the database in Cobol. Using Oracle's terms, there are the
HLI (high level interface) and PCC (precompiler). Some 4GL tools
generate HLI calls which can change from one Oracle release to another.
(I know because I'm involved with a customer who has a 4GL and is
stuck in this situation.) If the programmer uses the HLI (macro
like) interface, no precompiler is necessary and the code can be
compiled with optimization. The draw back of HLI is that Oracle
will someday (rumored in V6) not support this interface directly
and the programmer would have to learn the call structure each time
Oracle has a new release.
PCC works much like RDO and the entries in your Cobol program are
more civil. When the code goes through the Oracle precompiler,
HLI calls are generated and the VMS cobol compiler is invoked.
The advantage for the programmer to use the PCC approach is that he
is insulated from changes in the call structure because the precompiler
maps the PCC statements to the HLI syntax for that particular release
of Oracle.
PL/SQL is yet another interface to V6 with TPS. Noone seems to
know what it is or how it will be handled except that you will have
to modify your programs in order to get full performance boost from
V6 and TPS. (I'll know a lot more 2 weeks from now.)
Last week I did a benchmark on Oracle at the Los Angeles benchmark
facility using 5.1.22 and it was a disaster. Since the customer
identified the poor performance of Oracle (which caused us to fail
the benchmark) as a significant problem (.5 TPS max on 8820), they
are pounding on Oracle for a V6/TPS benchmark which we will run
on Friday, Oct 7. I will report the results of all benchmarks in
this conference after we're done. (By the way, we will still get
the PO for the system but customer is holding Oracle's 200K PO until
after the benchmark.) I'll also know more about the modifications
to the Cobol source as well.
Give me a call if you want to discuss ..... you can win Rdb battle
but have to sell Rbd unique features: backup, row level locking,
easy to manage, et al.
DON'T LET THIS GET OUT OF HAND .... ASK FOR PERFORMANCE RUNS AND
BENCHMARKS OF RDB VS ORACLE ....
Gerry Duncan @KCO
DTN 452-3445
|
| Linda, I suggest you look at the notes under DIR/TITLE=SIZE.
Also, Art Kamp in the London office may be able to help. He is working
at a customer at present who has standardized on ORACLE. Another
person with hands-on experience is Martin Kunaus (TRCO01::). Martin
was working at the Ontario Ministry of Health which is also an ORACLE
shop.
The trick is that you need to ensure the proper sizing is done and
that the local ORACLE office is on the hook if their estimates a
off. We shouldn't size systems but get ORACLE to do so.
TTFN
Paul
|