Conference ulysse::rdb_vms_competition

    
    Well, to quote the now-infamous Special Edition Competitive Update,
    ACMS and Rdb/VMS can achieve a 27 TPS rate on a 128mb 8830 using the
    industry standard Debit-Credit benchmark of 95%/1-second criteria.

    Don't know where the 2-3 TPS rate came from.

    What was that other comment about Rdb being "above 4GL" ???
    

    .1   The statement basically trying to say that Rdb performance
         is too slow for OLTP environment. Hence RMS is used instead,
         especially with the new RMS journaling in place now.
    
         "DEC has been repeatedly criticized for having chinks in its
         armour in regard to its present transaction processing
         capabilities but has apparently gone a step beyond filling
         holes with applications to mainstreaming the OLTP system at
         the RMS level of VMS"
    
         "But because of a new optional feature in VMS 5.0 called
         RMS journaling, major enhancements were made to the OLTP data
         base so that the transaction processing could be performed
         at the RMS level."
    
         Please comment on these
    
         regards, Jeffrey Choy   

    
    This is frightening rubbish, who are your local Product Managers?
    
    The "RMS being used instead of Rdb" sounds like an extremely erroneous
    interpretation of DECintact's role in life, and totally ignores
    the fact that the major thrust of recent announcements is
    OLTP-class p1rformance and volumes with Rdb being used with ACMS.
    
    Does the author work for Oracle ?
    
    

    Yeah, I agree with Chris.  It's hopelessly confused and wrong and
    misleading.
    
    I would suggest getting the facts from the Sales/Competitive Updates
    and then straightening out the poor customers.
    
    Jeez.  Why us?
    

I wrote up some information about this in the RDB conference.  V2.3 can
only perform 2-3 =>QUALIFIED<= DebitCredit transactions.  It can perform
6 (or even more) batch DebitCredit transactions.  Unfortunately, people
like to throw numbers around without qualification and chose whatever
number they want in order to make their point.  In fact, there was so
much disagreement over what numbers to use in the comparison, that the
announcement finally said that V3.0 was 2-10X V2.3!


>    .1   The statement basically trying to say that Rdb performance
>         is too slow for OLTP environment. Hence RMS is used instead,
>         especially with the new RMS journaling in place now.
>    
>         "DEC has been repeatedly criticized for having chinks in its
>         armour in regard to its present transaction processing
>         capabilities but has apparently gone a step beyond filling
>         holes with applications to mainstreaming the OLTP system at
>         the RMS level of VMS"
>    
>         "But because of a new optional feature in VMS 5.0 called
>         RMS journaling, major enhancements were made to the OLTP data
>         base so that the transaction processing could be performed
>         at the RMS level."

First of all, in the DECintact experiments, DECintact performs all of
the journaling.  The DECintact/RMS combination takes SUBSTANTIALLY MORE
I/O to perform a DebitCredit transaction than does Rdb/VMS (in the ACMS/Rdb
experiments).  The reason for the higher TPS rates for DECintact is the
CPU efficiency of flat file vs. relational database access.  VMS' RMS
Journaling isn't even a contender at this time.  The maximum DebitCredit
rate using VMS' RMS Journaling is in the 1 TPS range!

As has been pointed out before, Rdb/VMS does NOT use RMS for database or journal
I/O.  Databases are specially formated files that are accessed at the
QIO level.

The MOST I/O EFFICIENT data management choices currently available from
Digital are VAX Rdb/VMS (and VAX DBMS).  Further, VAX Rdb/VMS
performance equals or exceeds any competitive relational database
product. (I'm sure people will find individual applications where it
doesn't, but that's the joy of benchmarking)

As for the reference to "above the 4GL level", I can only say I wish.
I'd love to have a 5GL database system that can do 20ish TPS on a 6240!
I wonder what statement the reported aborted to come up with this gem.

One other little point, we had technical resources at the press
conference to answer questions, as well as having people available on
the phones to track down answers to questions the next day.  The only
computer publication that came and asked technical questions about the
database products was Digital Review.

Most of the questions actually came from consultants and analysts.  I'd
particularly point to IDC, who are making substantial efforts to
understand exactly what we did in V3.0, how it fits in with DECtp, and
where things might go in the future.

We've made substantial resources available to make sure the press,
consultants, and analysts could get the facts straight.  It's too bad
more of them didn't take advantage of our openness.

    Thanks for those feedback.
    
    .3  The author of the article is WILLIAM BRANDEL.
        Computerworld Southeast Asia is a weekly bulletin distribute
        in Asian countries. Computerworld SouthEast Asia has the same
        logo as the COMPUTERWORLD that we all know, and sometimes I
        do see similar article on both magazines. I deduced that they
        are the same company.
    
    .4 Unfortunately we do not have a local product manager for any
       product in specific. Most of the sales people including the
       Marketing are not so border about Rdb and related stuffs.
    
       I have spoken to our marketing communication specialist and she 
       needs from me firstly supporting documents to backup our claim
       and secondly an approval from the general manager.
       I feels that there is  lot of work for me if I want to pursue this
       matter and more important I will not be effective in this kind of thing.
    
       Alternatively, the proper function in DEC corporate should
       perhaps take up this issue as the article may be derived from
       the US source of COMPTERWORLD
    
       REGARDS, Jeffrey

Send all the information to the Database Systems Marketing
Communications Manager, John QUILL::Hill, and see if he wants to persue
it.  My guess is that it is best ignored.