Conference ulysse::rdb_vms_competition

                  I N T E R O F F I C E   M E M O R A N D U M

                                        Date:     05-Nov-1991 05:09pm AES
                                        From:     Keith Anderson
                                                  ANDERSON KEITH
                                        Dept:     Marketing
                                        Tel No:   [61] 6 2754832, 2 5617035

TO: See Below

Subject: RE: A: Oracle Presentation                                            

Rim et al

A few thoughts about ORACLE before the meeting that you should be aware of:

1.  I understand that the strongest corporate relationship with ORACLE is the 
    one that treats it as an ISV, providing "solutions" for marketplaces that 
    we do not otherwise have a range of product in. Interestingly, ORACLE's 
    cross platform migration theme can help us win business here (the opposite 
    to the trend elsewhere) by moving the customer from an original platform 
    to one of ours.

2.  The head of USA Sales has determined we need a "mature" relationship. Due 
    to our movement towards systems integration and information utility, there 
    are possibilities for occasions on which we must use ORACLE software and 
    services to solve customer problems. I'll try and find a copy of the sales 
    guide that the USA now have for working with ORACLE.

    The advantage of working with ORACLE in a SI opportunity is that we can 
    tie them down to contractual obligations for support and performance, 
    including penalties for non-compliance.

3.  However, generally the Australian field (Sales and Digital Services) 
    considers ORACLE a direct competitor in software (and even hardware). This 
    is based on experience : usually because ORACLE has transfered its 
    solution to a cheaper platform to save customer dollars, at our Sales 
    expense. In prior years, I heard tales of about half a dozen sales lost 
    due to ORACLE changing vendor away from us. My vested interest here is 
    SPG business.

4.  ORACLE sales reps are commissioned - and this seriously affects their 
    behaviour, at great cost to customer satisfaction and any working 
    relationship we attempt to build. Again, this is the experience given by 
    Australian and NZ Sales and support.

5.  The ORACLE strategic product direction is incompatible with that of 
    Digital, and especially with that of Dave Stone's The New Software Group 
    (TNSG). TNSG is responsible for the COHESION CASE program, the Information 
    Network program (DataBase Systems), and these two are incompatible with 
    ORACLEs software "lock-in" strategy. 

    ORACLE is attempting to be a single source of software for all major 
    platforms, by providing software product common across those platforms. 
    However, in order to protect their investment, their software is not 
    extensible or tailorable, the interfaces are not documented. Systems 
    Integration work on Digital software is very easy, but on ORACLE software 
    would be very technologically risky. 

    ORACLE's software rollout strategy is to provide: RDBMS, CASE, X.400 and 
    other MAIL, PC integration products. Imagine them selling products on our 
    platforms that utilise little or no NAS services, instead of Digital 
    products? 

    ORACLE threatens our SPG revenue far more than a lot of other vendors in 
    my opinion. 

6.  ORACLE have a history of being a marketing-driven organisation with very 
    little care for and support of installed base customers. In Australia, 
    poor ORACLE support has been an issue for customers.

7.  In the past, their advertising campaigns have been unfair, even while they 
    courted friendly relationships.

8.  VAX Rdb/VMS now outsells ORACLE on VAX, and is a much better product. 
    Expect this trend to continue.

9.  We should continue with ULTRIX/SQL on ULTRIX as RDBMS of choice, for 
    reasons of compatibility in the future.

10. In my opinion, there is a role for ORACLE in our future, but it is not as 
    a strategic CMP or OEM such as COGNOS, PRAXA, ANDERSEN CONSULTING. 

Regards
Keith

Distribution:  
[removed]

To give you an idea of what BULLC**P Oracle was feeding Hughes:

One point Oracle made was that they were sorry about the Rdb/NAS
advertisements.  They said they had "slipped though" despite internal
objections to them.  Well folks, they CONTINUE to "slip through" despite
all the Digital VPs kissing up to Oracle.  The latest Digital Review had
one.

    Careful- the wording is different.
    
    It no longer says "high margin VAX/VMS systems". Demmer's group was
    offended by that. 
    
    
    Barry

 Changing tack slightly....

 I look after a couple of the Electricity companies here in the UK. To
 cut a long story short, all 12 of the Electricity companies have a 
 VAX installed, running an Oracle based application. 

 A few of these companies are looking to expand their applications,
 (still built around Oracle, no chance of switching yet !!). However
 they need to upgrade their VAX platform. We are currently proposing a
 VAX 6410 to 6610 upgrade. They are really keen to go through with the
 upgrade, especially since the price is so competitive. However, the
 one big fly in the ointment is the cost of the Oracle license. Before
 the 6610 was announced, Oracle were looking to charge the customer
 150k pounds sterling to upgrade two systems. So, the customer understandably
 started looking at a way of reducing the Oracle license cost. (See my
 earlier note ref MEIKO data cache accelerator).

 We have tried to work with the local Oracle sales rep. Unfortunately
 she is a very hard nosed lady, who just spouts the party line, of
 Oracle not wanting to help Digital win hardware sales !!!! Also that
 Oracle aren't in the position of forcing a customer to switch hardware
 platforms either !!!! The customer is extremely annoyed and has threatened
 to withdraw from Oracle completely unless it does something about its
 licensing costs.

 I have heard rumours that Oracle in the US, are not charging for customers
 upgrading from 6410 to 6610 class machines. Can anyone confirm that ??

 Also one other point.... Can anyone tell me how Oracle license VAX systems
 running Ultrix ?? 

 We are starting to suffer from the high prices Oracle are charging the
 installed VAX based users.

 Regards.

 Kevin

    Welcome to the wonderful world of O-licensing.  The Center for
    Migration Services hears this story every day from more and more
    O-customers.  Our 1st recommendation is for the customer to put
    pressure on O to reduce licensing costs: if O does not listen then
    no more O purchases as the company migrates away from O (Digital and 
    3rd parties are eager and ready to help !)
    
    O pricing is not competitive with the rest of the industry.  Let's do
    what is right and put pressure on the bully.
    

Hi folks,

I want to tell you a little story about an incident one of our CSO's had.
This CSO has developed (ported) a  software-package to Rdb, and is now trying to
sell this throughout Scandinavia.

At a site in Sweden they were up against Oracle (financials as it were) and were
handed a very ineresting paper that was refering to the (in)famous TPC-B
benchmark of Rdb sponsered by Oracle.

Along with the result was a few comments done by Oracle (actually this paper is
an internal working document for Oracle Sales reps)
Note that all quotaing and uppercasing is taken from the original document.
All spelling mistakes are mine :-)

The result was that DEC Sweden actually asked (in private) if the CSO could
rewrite their code to use Oracle instead !!

The end: Unknown at this point in time, but I will post the result as soon as
the sale has closed.

Morale:
-Despite the events that has taken place at management levels O still throws mud
 around (espically note the very last line of the attached letter !!)
-DEC people still don't understand the impact of selling to O, they think
 it is a win (sometimes even a must)
-Don't trust any O persons word, make them do everything in writing

Cheers
Lars

Ps. If you want a copy please mail me your FAX number and I will sent it to you.
There is no copyright statement anywhere.

The letter O gave to the CSO.
-------
Headline was:
Questions to ask Prospects:
1) Oracle 2.5 times faster than Rdb. Can DEC really be commited to building a
good RDBMS ?
Do they know how to build one ??

2) Oracle nearly twice the price/performance. Is Rdb really free ??

3) Rdb: POOR DESIGN, POOR EXECUTING, Can you risk your business ruinning on
this?

4) DEC Claims that the SMP technology is very good. Why wont the Rdb group
release benchmarks that tells this


Then about half a page around how to fight Rdb !

Use these facts to WIN in the VAX/VMS environment. Write to INFOVMS for details
and total system cost to counter myths about Rdb's low cost. Reveal the truth
about Rdb's poor scalability on SMP to deflate claims about Rdb's performance
and integration with VMS.

For more information about the benchmarks results, contact infovms.
For a reprint of the benchmark full disclosure report, order part 522252-1091.

Then another paper is added to end of the first:

QUESATIONS TO ASK YOUR PROSPECTS:
*Did Rdb group cheat since the TPC-B number were withdrawn ?
*Why did TPC ask DEC to withdraw the number
*If DEC claims they they withdraw the numbe voluntarily, ask them if they believe
 if most companies run expensive benchamarks just to withdraw them AFTER they are
 filed.

* If the impact of the "techniques"DEC used were only 5%, then why didn't you
re-run the benchmark -- even if just to salvage your reputation ?
(the relaity: Because the impact was more like 60%, that's why !!
In their recent TPC-B Database Assocates found that techniques similar to those
that led to disqualification, raised Rdb's 3-processor performance from 57TPS to
93TPS)

* Why doesn't Rdb have any TPC-B numbers currently

* IF Rdb's smp-scaling is so good why dont they run on their flagship
6-processor smp machines

GOOD SELLING !!
DEC Product Division

Register your referencable VMS Accounts with INFOVMS and CRUSH Rdb



    

�   <<< Note 1023.6 by COPCLU::BRUNSGAARD "Curriculum Vitae, who's that ??" >>>
�                -< This is the Oracle sales guide against Rdb >-

A few general comments first :)

The first page of this is the same information that was thrashed to death 
in note 1017 so check that out also...

The other pages of this is something we haven't seen before (at least that 
I'm aware of).

Now, to cover some of the specific points...

�QUESATIONS TO ASK YOUR PROSPECTS:
�*Did Rdb group cheat since the TPC-B number were withdrawn ?
�*Why did TPC ask DEC to withdraw the number
�*If DEC claims they they withdraw the numbe voluntarily, ask them if they believe
� if most companies run expensive benchamarks just to withdraw them AFTER they are
� filed.
�
�* If the impact of the "techniques"DEC used were only 5%, then why didn't
�you re-run the benchmark -- even if just to salvage your reputation ? (the
�relaity: Because the impact was more like 60%, that's why !! In their
�recent TPC-B Database Assocates found that techniques similar to those that
�led to disqualification, raised Rdb's 3-processor performance from 57TPS to
�93TPS) 
�
�* Why doesn't Rdb have any TPC-B numbers currently
�
�* IF Rdb's smp-scaling is so good why dont they run on their flagship
�6-processor smp machines

Digital ran both TPC-A and TPC-B benchmarks.  TPC reviewed the benchmarks 
and felt there was a difference in interpretation in the rules between how 
we ran both -A and -B and how TPC felt they should be run.  This difference 
in interpretation dealt with the way that we used dbkeys (the use of dbkeys 
wasn't the issue, but how we used them).  TPC gave us a choice of 
re-submitting the benchmarks with the changes to the use of dbkeys or 
withdrawing the benchmark.  TPC DID NOT ASK US TO WITHDRAW!  

It was determined that changing the use of dbkeys for the -A benchmark to 
fit TPC's interpretation caused a change in the benchmark performance of
less than 5%. 

We choose not to re-run the -B benchmark since -B rules had been changed 
and we would have had to change more than just the dbkey usage so we didn't 
feel this was worth our while.

In addition, we are always running benchmarks.  Marketing makes the
decision which benchmarks will be advantageous for us to publish... 

A few things for you to feed your customers and management...

Digital runs our benchmarks at isolation level 3.  What does Oracle run 
theirs at?  If it's different than level 3, is it really a fair comparison? 
You will see differences in performance depending on the isolation level 
being used in the transaction/application.

Where are Oracle's TPC-A benchmark figures?  -B is felt to be a database 
stress test.  How many customer applications are a "stress test" against 
the database?  Most customer applications are just that, applications.  -A 
is felt to measure the application environment.  Why doesn't Oracle measure 
that (or at least publish their measurements)?

    re -1:
    
    What is "isolation level 3"? Is that the same as degree-3
    consistency?
    
    Thanks,
    Henny Olthof, TP-DB Netherlands

    re .6
    Thanks Kathy,
    
    I should of course have told you, but I have already feed them with the
    official answer about this. Just felt like this would be interesting to
    publish, so hopefully (eventually) someone will open their eyes and see
    what is REALLY happening in the field.
    
    Re .8
    Not quite Henny
    TRake a look in the Rdb Notes file a note by Hal Berenson (can't
    remember the number of my head).
    
    Lars

    Re .8 Just found the note:
    
    It is Rdb note 381.1

Isolation level 3 is when the database system does not allow phantom updates
and allows repeatable reads.

-Jay

�  <<< Note 1023.10 by COPCLU::BRUNSGAARD "Curriculum Vitae, who's that ??" >>>
�                              -< Rdb Note 381.1 >-

In the RDB_WISH conf :)  and here for your reading pleasure :)

Included without permission (since Hal is on vacation).


             <<< NOVA::NOTES_DISK:[NOTES$LIBRARY]RDB_WISH.NOTE;1 >>>
                      -< Rdb/VMS Wishes and Suggestions >-
================================================================================
Note 381.1               Allowing degree-2 consistency ?                  1 of 1
COOKIE::BERENSON "Lex mala, lex nulla"               44 lines  10-DEC-1991 11:26
                            -< Under consideration >-
--------------------------------------------------------------------------------
ANSI and ISO are redefining things for SQL2.  Forget about the previous
definitions of degrees of consistency.  We now have Isolation Levels.
These levels are defined in terms of the phenomenon that they allow the
application to see.  Three phenomenon are Dirty Read, Non-Repeatable
Read, and Phantoms.



Level           Dirty Read      Non-Repeatable Read     Phantoms

0               YES             YES                     YES
1               NO              YES                     YES
2               NO              NO                      YES
3               NO              NO                      NO

"Degree 3 Consistency" and "Isolation Level 3" are equivalent.  "Degree 2
Consistency" and "Isolation Level 1" are equivalent.

With Dirty Read you can see uncommitted data.  Some reporting
applications would work ok despite this.  And, the benefits would be no
blockage by locks of other processes and a drop in path-length do to
reduced locking.  

With Non-Repeatable Read, it's possible for you to read
some data and then have another application read/update/commit a change
to that data before you can update it.  The result, of course, could be a
buried update (although this can be avoided by using an UPDATE ONLY
cursor to re-read the record once you've found the one you want to
update).

Phantoms make some relationship kinds of queries function incorrectly,
but those queries appear to be rare in practice.  The benefit of dropping
phantom protection is that there would be a lot less contention on b-tree
indices.  Thus, applications which work correctly without phantom
protection and currently experience lock contention on indices would
benefit by isolation level 2.  In fact, I suspect that most applications
could be converted to isolation level 2 without harm.

We are seriously considering support for isolation levels 1 and 2 (in
addition to our current support for 3) in the MNR.  Right now there are
no plans for level 0, but we'd certainly be interested in understanding
applications that would benefit by it.

Hal