Conference ulysse::rdb_vms_competition

    Surely you can get the support that you require from Oracle!?
    If you think thats being sarcastic- its meant to be.
    A colleague of mine recently presenting Rdb futures to a senior
    VP of a "major" account was interupted with a "time out" gesture.
    The reason - this VP wanted Oracle futures and performance details!
    As of this date Oracle Corporation are not even a CMP. This VP also
    wanted to know why they were not one.
    Some days are better than others.
    I do hope that the hardware business is ours in this notes case
    -at least today if not in the future with portable Oracle!! 

    I had same kind of questions with INGRES and ORACLE, as far as I
    have heard, both of those products don't have AIJ-support in 
    VAXcluster-environment (ORACLE will have in release 6, INGRES ?).
    
    Regards
    Kari Hirvonen Digital Finland/SWAS

This is unbelievable!!  A person in a group chartered to "support strategic 
sales" actually wants to provide work-arounds for the pit-falls of our 
MAIN competitor's product!  And Rdb/VMS is declared a strategic product.

 You've lost me.  Maybe I'm too new at DEC, but this stuns and upsets me a 
lot.  These events are not isolated things, I've seen similar request 
before.

 I do understand that Oracle is for real, and that we have to live with it, 
but to activly cover up product deficiencies is going too far.  At least in 
my (naive?) opinion.

 Hopefully this is all due to lack of information as to what Rdb is and 
will be, functionally and competitivly?  

 So, educate the customers about the pit-falls, and give them the best 
work-around: Rdb and its relatives!

(Wow, I feel much better now after this BOHA - blowing off hot air! :-) )

Lars

    Its all very nice to carry the RDB banner but the reality is that
    a number of customers have decided on ORACLE. Here in Ontario Canada,
    most of the Ministries (AKA Departments to our U.S. cousins) have
    adopted ORACLE as their strategic product.
    
    BUT you do have a point that we do not have to do their job for
    them. Whenever I am asked to assit on a configuration involving
    ORACLE, I get on the phone to my local ORACLE rep and get them to
    do the leg work and more importantly ASSUME RESPONSIBILITY FOR THE
    SIZE OF THE SYSTEM.
    
    As to the origianl question, my ORACLE contacts admit that ORACLE
    in a CLUSTER is very costly. The reason, I'm not sure, but I think
    it mostly has to do with the fact they do not use the distributed
    lock manager and have implemented their own scheme which substantially
    increases I/O's.
    
    Its ORACLEs problem, DBM (don't buy monkeys).
    

    I apparently, inadvertantly stumbled onto a religious issue. Please
    allow me to clarify me position on this (and my loyalties if in
    doubt).
    
    For those of you who checked my intro you know that my background
    is as an ORACLE OEM. Which is precisely why I would rather  NOT
     see ORACLE succeed in our accounts.  After 3 years of being held
    over the cliff (until we came up with enough money to temporarily
    gain solid footing) with each major release of ORACLE, I believe
    that while ORACLE is product is OK (yes just OK), ORACLE the company
    is vicious.  This viciousness is not reserved for OEMs.  End users
    have also been held for ransom. Ask any customer of ORACLE's who
    has had the product from Version 4 or prior how much is has cost
    them (above the maintenance fees) just to keep up with the latest
    releases. Probably 2 to 5 times their original investment in ORACLE.
     
    I also believe that it is "strategically" imperative that Digital
    OWN the customers data (within a proprietary DBMS) to maintain account
    control.
    
    Now comes the "On-the-other-hand" part.
    
    On the other hand, Customer Satisfaction is one of our major stated
    goals and is critical to our current success and future prospects.
    
    If the customer has made a Digital/ORACLE decision, after having
    been presented with what we are convinced is the best solution (Rdb)
    then it is still our responsibility to ensure the customer succeeds
    with at least the Digital part of the solution. A failed project
    doen't reflect well on any of the involved parties. While some
    customers may be intelligent enough to recognize ORACLE as the culprit
    I would not want to wager one of our larger customers on this hope.
    
    In regards to having ORACLE Corp. take the lead in the data base
    project success:  While in principle I agree and in many cases would
    make the same recommendation, it can hardly be denied that the
    customers loyalties will lie with the vendor who participates most
    visibly in their success.  Our continued involvement provides us
    with the necessary account control and minimizes the risk of ORACLE
    successfully migrating our customer to another platform.  In other
    words if the customer must have ORACLE then we should remove or
    minimize ORACLE Corp's involvement after the sale.  This also positions
    us well to replace ORACLE with the appropriate solution (Rdb) at
    the first opportune time.
    
    This particular customer is certainly aware of the availability
    of ORACLE Corp to help them resolve their problems but felt that
    Digital was the more capable provider. I personally would like to
    foster this attitude rather than kill it.
    
    Finally, I would like to solicit your input as to the best approaches
    for successfully selling Rdb to corporate accounts who have already
    standardized on ORACLE (or another DBMS vendor). This tends to be
    a rather daunting obstacle to overcome and we can all benefit from
    suggestions in this area.
    
    The Defense Rests...
    
    Sandy