[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference ulysse::rdb_vms_competition

Title:DEC Rdb against the World
Moderator:HERON::GODFRIND
Created:Fri Jun 12 1987
Last Modified:Thu Feb 23 1995
Last Successful Update:Fri Jun 06 1997
Number of topics:1348
Total number of notes:5438

417.0. "Oracle to Rdb conversion/Interoperability" by BANZAI::STATA () Thu Aug 31 1989 18:35

    Under the heading of those who don't ask don't receive -the following:
    
    A recent meeting with the group which supports 3rd party conversion
    services (ie ACES for RIB) the following question was raised.
    
    Why do we need to develop Oracle to Rdb conversion tools/support? we
    are never asked to support it.
    
    My feeling is that this is a chicken/egg problem. Since it doesn't
    exist it never gets asked for.  Also this may be an emerging need
    rather than long term issue since Oracle is just now competing for the
    applications, CASE, Service, as well as DB. Account control (or even
    presence) is becomming a concern in some industries and accounts.
    
    If you want this capability made available let us know. Send mail to
    
    Phil Cudia at Hillst::cudia with a copy to SQLRUS::STATA
    
    We have access to such tools and can make them available if there
    is sales, volume sales or services interest in having them.
    
    Chuck Stata
     
T.RTitleUserPersonal
Name
DateLines
417.1No more Tootsie Rolls!SRFSUP::LANGSTONeclectic soulTue Sep 05 1989 20:0313
    What with the large installed base of ORACLE's RDBMS on VAXes, I'd
    say we need little other justification for such tools.  
    
    Since we're supposedly spending big development bucks on Rdb and
    tools, and it is evidently paying off in sales, performance and
    chasing away the competition terms, another weapon in our arsenal will 
    be welcomed, I'm sure.
    
    After all, we should be thinking of ways to convert some of those
    many VAX/Oracle installations out there to RAX/Rdb before someone
    else (guess who?) converts them to SEQENT/ORACLE or NCUBED/ORACLE!
    
    -bpl
417.2Go For It!KYOA::HANSONWhere'd he get those wonderful toys?Tue Sep 12 1989 16:3575
    
    Phil, 
    
    I would support it wholeheartedly!  And, if such a tool were available,
    I would make it a point to go out, armed with this capability, and 
    start knocking Oracle-heads about.  You are soooo correct... it is 
    a chicken/egg problem.  If Sales feels that we don't have a solution
    to a given migration/conversion situation, then they will tend to 
    avoid that situation, taking the path of least resistance towards
    making their budgets (possible large generalization, here,) by 
    selling only those conversion solutions that are readily available.
    Read on:
    
    o I met you in Providence recently.  I'm Sales Support for the NY/NJ
      Volume Recruiting Unit.  It is, of course, our charter to recruit
      new OEMs (VARs, CMPs, whatever.)  I've heard about your group and
      have accounts that are currently using ACES/PS under RIB funding.
    
    o I'm looking forward to the solutions that your group can provide.
      It seems inane, sometimes, that a company with the size and stature
      of Digital, realizing that just about *everyone* in the world now
      has some sort of computer, cannot find it reasonable to provide
      clear and concise migration pathways from Product X to VAX/RISC,
      especially considering that we really want people to run on our
      platforms.  The issue, for any conversion group, usually comes 
      down to a matter of Funding.  To that end, I think that the solutions
      that your group currently can provide are a Godsend.
    
    o Customers, knowing that a potential migration will most likely be
      long, expensive, and painful, DO NOT wish to fund such a project.
      Indeed many almost seem to expect the vendor to convert them quickly,
      easily, and with a minimum of expense.  'Ay, that's the world today.
    
    o So, which is an easier sell?  Telling a customer that we have a
      toolset available and ready to roll, or telling him/her that if they
      put forth a certain (large) amount of cash, we'll develop a tool or
      turn it into a custom project?  (It's a rhetorical question.)
      We'll make better margins, and attract more customers when we're
      able to tell them that we have a pre-established migration pathway
      managed by a group that demonstrably has their collective guano
      together.
    
    o I, and one of my peers, have been 'round & 'round in the
    conversion space for many years now, and it seems that each time we
    investigate a migration pathway it's a new story.  Funded groups that
    have provided us with top notch solutions get nuked.  Non-funded groups
    are difficult to deal with due to a lack of funding.  (This often winds
    up to be a case where the customer is willing to convert and will pay
    a certain number of dollars, but cannot extend themselves to the total
    cost of developing a "custom" migration solution.  The opportunity
    winds up to be a bust because no one can find it within themselves to
    commit dollars.  What a pity!)  Third party solutions often wind up
    washing out because they can't stay current (tools break over time)
    or the solution becomes atrophied due to a lack of DEC committment
    in selling the conversion.
    
    o Bottom line:  ACES/PS WILL be useful.  I would actually call it a
    Blessing, for it serves as an insulating layer, oftimes, between DEC,
    the customer, and the technology of the solution.  But, VAR recruiting
    and software ports will only be largely successful if and when we can
    go into the account, demonstrate that we have a porting solution in
    place, manage and deliver the solution without gyrating amongst various
    groups, all with a minimum of pain & bucks.  I guess the message here
    is that we have to have these solutions in place BEFORE the sale, not
    after.  And, if you provide any given solution, such as ORACLE to Rdb,
    I would support, recommend, and participate in a concerted effort to
    sell that solution.
    
    I'm afraid that I've run on a bit here (apologies....) but it's clearly
    an issue with my group.  Phil, call if you'd like to discuss this
    further.  In the meantime, I have a couple of opportunities for you!
    
    Best regards,
    Bob
    
417.3When I was young I **liked** Oracle...USHS11::SPARKSI think, Therefore I am Mon Sep 18 1989 17:2626
    I've used Oracle since 1981 v2.* days.  My last residence was at a site
    beta testing v6.0.26 .  If this is an example of their new database
    technology, I think a conversion package would be very timely.  I had
    been somewhat of a fan of Oracle's product until 6.*.  I know the older
    stuff was slow, and had performance problems, but it worked and was
    dependable.
    
    I question if V6 will ever work right and have the stability of the
    older products.  I tried and could not find the performance increases,
    especially on queries.  Unless I miss my guess query is slower on V6.
    
    Database corruption is another story, every time I tried to do
    something on the V6 database it was corrupted or not available. 
    
    I may be wrong, but I think we will see more and more users with Oracle
    begin to show interest in RDB, a conversion process would help.
    Yoy can overlook a lot problems when you are convinced you have the
    best, but a corrupted database gets everyones attention.
    
    The problem is everyone hates to admit that they made a mistake, and
    with the Oracle bandwagon going full steam, they don't see how they
    could have made an error.  After all 20% (Oracles estimation) of the 
    VAX DBMS users can't all be wrong, can they?   You bet they can and are!
    
    
    Sparky Who_is_real_glad_I'm_not_responsible_for_an_Oracle_system_now
417.4If not tools, how about guidelines from veterans?ACESMK::QUINNTim - Corp. SWS/E Commercial ACESThu Sep 21 1989 23:0117
    My only knowledge of Oracle I glean from their advertising (!) and the
    notes in conferences like these, so excuse me if this is a dead end. 
    In the absence of executable tools to perform conversion and migration,
    would it be possible to prescribe in general the things to consider in
    performing such a conversion, even though you might have to do the
    steps "by hand" without a software tool?  
    
    What I'm thinking here is that although customers (understandably)
    might not want to fund development of a custom tool, they might be
    willing to pay for some migration help in the form of consulting time,
    assuming it would cost less than the tool!
    
    -IF- we were able to say "Yes, we understand the conversion need AND we
    have guidelines assembled by veterans of previous Oracle-to-Rdb
    conversions" might we not get some buyers?  Are there any such veterans
    out there who could capture their experiences and sketch out some
    guidelines?
417.5Real live conversion candidate!GLDOA::CAMPBELLPat Campbell (419)891-5411Wed May 09 1990 06:1116
    I have a customer dying to get off of Oracle and on to RDB now that
    they've purchased their first VAX (6410) and have started to play with
    it.  We competed against Oracle financials (VAX-based), Software 2000
    (AS/400-based) with ROSS in order to replace home-grown financials
    based on Oracle and won in November.  Customer is paying $35,000/yr in
    support costs, with service that PALES in comparison to our Colorado
    support center.  When they are done bringing up ROSS, they will have
    only a purchasing system left on their DG/Oracle which they want to
    port to a Mvax in order to dump both DG and Oracle.
    
    Question:  Should I use ACES or Trifox?  (see note 438)
    
    YES WE NEED CONVERSION TOOLS!!!!!!
    
    Pat Campbell
    Sales Exec